Re: The big question : Codec recognition from

Arpi wrote:
 >>Easier way is to convert to "MCF format" (like Steve said, could be
 >>closely related to one currently existing format) when muxing. With
 >>this, codecs only need to know how to convert to/from "MCF format".
 >
 > Yes, it's the other option. It sounds easy and perfect, but the
 > implementation is a big mess. As i already said, theye is no general
 > way to convert between vfw, qt, rm etc codec data. Either your
 > demuxer/converter will be full of if() and it should know all these 
codecs,
 > or the codecs should support all the formats the codec is used with.
 > I vote for the later, it's MUCH simpler. Having the demuxer to know the
 > codec internals is a very bad idea.

Yep, I haven't thought of a nice way of handling this. It would probably 
not automatic, at least for conversion. I think the AVI to MCF 
conversion tool should know some of the codec it can handle (from the 
"unlimited" list of existing ones) directly to "MCF native format".I 
can't think yet of a more general way of doing this. Unless each Transor 
knows what AVI wFormatTag, AVI FourCC, QT FourCC, etc it corresponds to...

 > Anyway both raw and mjpeg are very problematic ones.
 > 16bpp in AVI actually means 15bpp, while 16bpp in QT means 16bpp. The raw
 > codec should know it and fix it. It's done by fourcc in mplayer, as raw
 > fourcc in avi and qt are different.
 > MJpeg si even worse. There are field info (ordering etc), optional
 > huffman tables, optional coeffs etc depending on the actual codec dll.
 > there are at least 5 different mjpeg codec DLL for vfw, and they are
 > incompatible, while using the same fourcc. I wonder if you expect a 
DLL to
 > decode all mjpeg formats and also qt mjpeg and raw mjpeg too...
 > Every dll has its own private parameter/table struct stored in 'extra 
data'
 > part of BITMAPINFOEX.
 >
 > About the native codecs - they know N variants of the codec and 
detect&support
 > their data format. It was a big and messy work mostly done by Alex to fix
 > mjpeg decoder to work with all DLL codecs and also qt and other hardware
 > encoders.
 >
 > So, I'm pretty sure that parsing/creating codec dependent info must be
 > implemented in the codec or the codec wrapper, not in the muxer/demuxer.

Let's go for the codec wrapper (called Transor).