[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
>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
:-( .... 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