Re: The big question : Codec recognition from

> 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.

Demuxer knows nothing. Transors do. There are one or more Transors for 
each format. There are external dynamically linking libs that can be 
developed by anyone (preferrably by codec developers, but MCF developers 
will have to code many of those until codec developers take it 
seriously). Transor makes sure that it outputs data in correct format, 
so that the application can pass it for libmcf that muxes it.

> 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.

MCF uses 16 octet string as primary identifier. For 15 bit RGB, a string 
like "RGB-5-5-5" should be used, and for 16 bits "RGB-5-6-5".

> 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.

Uh. Looks like a lot of work for Transors, but also solves many problems 
(extracting QT MJPEG made by a digital camera with any of those five VfW 
codecs).

> 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.

Agreed, see above.

- Tronic -