On 2009/08/31 09:58, Jacob Meuser wrote: > On Sun, Aug 30, 2009 at 02:41:32PM +0200, Marc Espie wrote: > > On Tue, Aug 25, 2009 at 02:47:02AM +0000, Jacob Meuser wrote: > > > On Mon, Aug 24, 2009 at 06:23:46PM +0100, Mikolaj Kucharski wrote: > > > > On Mon, Aug 24, 2009 at 04:51:49PM +0000, Jacob Meuser wrote: > > > > > could we move the support for win32/real/qtx codecs to a flavor? > > > > > > > > > > currently, one has to have machdep.userldt enabled to play WMV/WMA > > > > > files, even if mplayer doesn't really need to load the codecs to > > > > > play the files. this is because when mplayer is built with support > > > > > for the binary codecs, it tries to probe the codecs when opening > > > > > a WMV/WMA file. then mplayer exists asking you to enable > > > > > machdep.userldt. this doesn't happen if mplayer is built without > > > > > support for the binary codecs. it just plays the files. > > > > > > > > Does that mean that binary codecs have precedence before other codecs? > > > > What happends if you change order of vfm/afm in config? > > > > > > > > I would prefer to have it enabled by default. > > > > > > I really don't think it's a good idea to mess with mplayer internals. > > > either a win32, or if most people really really want them by default, > > > a no_win32 flavor. let's keep it simple, please. > > > > More flavors is not more simple. Just the contrary. Especially when you > > have to deal with twice as many error reports... > > > > It also means users have to make choices as to which flavor they install. > > And this grows bulk build times as well. > > > > Can we just stay away from flavors and fix this for real ? > > > > fuck it then. I'm happy with my local update of mplayer. I'm not the > maintainer of this port anyway. good luck.
fwiw, I'd be totally happy not adding a flavour and just disabling the binary codecs outright, it used to be needed in order to play a significant number of files, but native codec support is pretty reasonable now, I don't think we need to keep on encouraging people to use the untrusted, binary-only, and almost certainly insecure codecs.
