Re: Re: The big question : Codec recognition from

Hi,

> > could you list these formats, available for more than one mm system?
> 
> MJPEG and all "raw" formats (YUY2, RGB24, etc) come to mind.

Hmm, yes. True. Also count mpegs, cinepak and DV.

> > so, imho for such multi-system formats the decoder should be able to accept
> > all kind of mm system headers (where the codec exists) and translate them to
> 
> If MCF can contain stuff for any codec/system, and there are, say, 3 
> different systems, this means that all codecs will have to support all 
> three options. (VfW codec would need to read VfW, QT and RM)
> 
> 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.

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.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu