[matroska-devel] Re: AVI compatibility mode?

Christian HJ Wiesner chris at matroska.org
Mon Feb 17 15:42:02 CET 2003

Hi mosu !

Moritz Bunkus wrote:

>Sunday Cyrius and I had a rather long discussion about the 'AVI
>compatibility mode'. He told me he'd save the BITMAPDONTASKMETHATNAME
>and the WAVEHEADEREX and other structures in KaxCodecPrivate and didn't
>set all the KaxVideo* elements.

Well, than Cyrius is lazy and doesnt make things correctly :P . For AVI 
compatibility mode the plan is to

- copy the above mentioned structures into codec private data. This is 
necessary to be able to call the corresponding DShow filters on Windows
- extract all the necessary info for matroska elements from there also 
and set the elements accordingly, especially with respect to x-platform 

>This was the first time I actually heard about such a compatibility
>mode, and I was a bit confused why anyone would want to do such a
>thing. That's why I'd like some clarification on that point.
>Some disadvantages that I can see right now:
> - These structures are Windows specific. Neither Unix/Linux nor MacOS
>knows about them.
Yes, thats why we always said AVI compatibility mode will behard to 
support on other platforms, and this mode should be avoided as good as 
possible ! Unfortunately we dont have UCI plugins available for the time 
being ( as UCI is not ready ), and such plugins should be used normally 
to create 'native' audio/video streams using a matroska ID

> - These structures are stored as they are lying around in memory which
>produces the usual Endianess problems.
> - Why use separate structures that are not coded in EBML if Matroska
>itself contains elements for the contents? e.g. KaxVideoPixelWidth etc.
See above, thats the plan. AVI compatibility mode is a fallback system 
to be able to support

- older codecs that are availlable only as VfW or have an unusual FourCC etc
- make the adressing of DShow filters for playback on Windows relatively 
easy, as there will be only a very small number of UCI decoder plugins 
during the first years, or none at all ( like for the time being :-(  )

It was always the plan to DIScourage the use of this mode, to enhance 
x-platform compatibility.

>If there are any fields in those structures that are necessary or even
>only important and there's no Matroska element for storing this piece
>of information, then Matroska should be changed.
matroska has elements for every single piece of information that is 
stored in the AVI structures, except those we dont need for matroska ( 
dont ask me what these are though )

>Another point: I now know that there are dummy frames in AVIs if B
>frames are being used. I understand that you want to store that fact in
>Matroska in some way. But there's alreadly KaxCodecID...
The original plan was to differentiate clearly between an MPEG4 video 
stream coming from an AVI ( including b frames ) and an MPEG4 stream 
being produced with a native MPEG4 UCI plugin, storing b frames using 
the matroska b frame elements, and not using dummy frames. First should 
be stored in AVI compatibility mode by all means, so its clear this was 
muxed from an AVI. Second could be the result of
- a native MPEG4 UCI plugin
- a demuxed AVI that is reordered in that way that the b-frames ( they 
are attached to the I/P frames in one single chunk now IIRC, Alex 
Stewart has explained that perfectly ) are released from the I/P frame 
chunks and inserted where the dummy frames are sitting right now. That 
way we wont have dummy frames in native streams with matroska codec IDs 
anymore, reducing overhead and keeping the right frame order ( coding 
order, as recommended by Alex several times and agreed by Steve ).

>Another question: if I use 'V_MS/VFW/FOURCC' for the CodecID (as I'm
>reading an AVI) - where do I store the FourCC?
The FourCC is stored in the BITMAPINFOHEADER structure, Cyrius should be 
able to tell you the name of the tag.

>says 'see codec 'private' data and use suitable decoder based on FourCC
>code' but where do I then store e.g. the Huffman tables required by the
>MJPEG codec? 
:-( .... i know that there are a couple of codecs that are clearly 
breaking the AVI specs by putting some important data into the AVI 
comment fields. HuffYuv is doing the same shit, storing huffman table 
there same way as MJPEG does. Its true, we have to define a way how to 
do that !! I would suggest they go into codec private data also, but 
Steve would be the one to ask here for final clarifying.

>And why does the spec say that CodecID is 128bits long
>with the upper half being reserved? Aaaaaaaand...
?? It should by 16 bytes long ? are you sure ? maybe an error in the 
spec, or is this an EBML element ?

>Next question. Well... I'm sure I had another question, but I can't
>remember it right now ;)
Thank god !! lol .....




More information about the Matroska-devel mailing list