Hi, Von: "François Revol" <revol@xxxxxxx> > Le 22 sept. 2010 à 14:51, Stephan Assmus a écrit : > > Von: "François Revol" <revol@xxxxxxx> > >> Le 22 sept. 2010 à 13:10, superstippi@xxxxxx a écrit : > >> > >>> Author: stippi > >>> Date: 2010-09-22 13:10:51 +0200 (Wed, 22 Sep 2010) > >>> New Revision: 38786 > >>> Changeset: http://dev.haiku-os.org/changeset/38786 > >>> Log: > >>> Enabled any and all decoders and demuxers which are currently compiled > >> into > >> > >> > >> How about apps that want a decoder for avi:'divx' ? > > > > Huh? What apps? You can't hardcode such constants anyway. How would you > know there is an encoder installed for fourcc 'divx'? Perhaps there is one > for 'DiVX' instead, or it's 'XViD', all the same thing. The whole matching > was really fragile before, lots of duplicated entries with slightly > different spelling, sometimes bigendian, sometimes not... and we still didn't > handle all files we potentially could. As I understand it, the format family > nonsense only exists, because -- theoretically -- a format family defines a > codec tag name space, and the same tag in two format families could actually > mean a different codec. In practice this does not happen, and we have a > lot of container formats that don't even use fourcc tags at all. The only > meaningful situation in which an app asks for specific formats and codecs, is > when encoding. The FFmpeg plugin has been the only plugin supporting > encoding anyway, prior to my commit, and applications can still ask for > specific > codecs and file fo > > rmats. That is not affected by my commit. If that's not what you mean, > could you be a bit more verbose? :-) > > I was thinking more of apps using decoders directly like BMediaDecoder. > Things like IM clients which usually need codecs by 4CC from the same > namespace as AVI or MOV... If nothing else, we could define IDs for codecs like it's already done for mpeg codecs. Best regards, -Stephan