AVI-Mux GUI

Some notes on Open-DML...

back to main page

The original, old AVI file format (sometimes referred to as "AVI 1.0") allows file sizes up to 2 GB, even if the file system would allow larger files. The reason can be found in the basic file structure:


RIFF:
    4 bytes     :  RIFF_ID
    4 bytes     :  size     <- signed value!
    4 bytes     :  RIFF_type
    size-4 bytes:  data

In order to break this limit, the Open-DML extensions to the AVI file format were specified by 06/28/1996, also referred to as "AVI 2.0". The most important extension is that several RIFF items of 2 GB each can be appended, which removes the 2 GB limit. Support for AVI 2.0 is pretty good nowadays, you can use them p.e. with VirtualDub(Mod), as well as with every program based on DirectShow. It does typically not work with hardware MPEG4 players supporting AVI files.

If you have used older versions of AVI-Mux GUI to create Open-DML files, you might have encountered weird problems, such as that only one out of 2 output files has worked, or that an output file only worked in some players. AVI-Mux GUI, as well as VirtualDub, never had any problems reading and processing these files.

The problem is that Microsoft's support for Open-DML is not really complete. It is no problem at all to create Open-DML files that meet all specifications, but that do not play in DirectShow! Of course, Microsoft's AVI splitter supports all Open-DML files created with Microsoft's AVI mux filter, so you haven't encountered this problem if you have used muxing applications using this muxer. However, since AVI-Mux GUI uses an own muxer, it can create files containing 'features' that are spec compliant, but that do not occur in files made with Microsoft's AVI mux filter.

Open-DML files use a different index format, compared to old AVI files, which uses less overhead (33% less). Nevertheless, it is allowed to add an old index ("legacy index") to make the first part of the file 100% compatible to the old AVI format. Unfortunately, this creates 16 bytes of additional overhead per chunk. Until AVI-Mux GUI 1.16.2, I thought that this did not make any sense provided that the created Open-DML files are DirectShow-friendly. However, after installing Windows XP on my own, I was able to really run a few tests, and I realized that a bug in shmedia.dll causes the entire file to be read if you click (!) on it. It turned out that the first RIFF structure is completely parsed if it has no legacy index. The fix is to write a legacy index, but to create a first RIFF section of only 1 MB. On the one hand, this prevents shmedia.dll from reading a large section of the file, on the other hand, it avoids too much overhead caused by the legacy index in the first RIFF section.

That's why Open-DML output is now activated as default, while legacy index is activated and set to a range of 1 MB.

Low overhead mode

The Open-DML specification seems to allow an interesting interpretation of the index structure: As the index points to the video and audio data directly, and as the specification does not really mention that a chunk header must precede a data chunk, it seems to be a valid option to put several video or audio frames of the same stream into one chunk, create an index entry for each frame, and then force an AVI reader to use the index for retrieving single frames by setting the AVIF_MUSTUSEINDEX flag in the headers.

Doing this decreases the overhead by almost 50%, compared to "normal" Open-DML files (that means 66% compared to AVI 1.0). Microsoft's AVI splitter can read such files correctly, as well as VirtualDub(Mod) and Haali Media Splitter. Gabest's AVI splitter in MediaPlayer Classic up to v6.4.8.2, as well as lots of Linux tools, don't like files created that way, newer versions of MediaPlayer Classic work with such files. The first version of AVI-Mux GUI to be able to write such files is 1.16.11. I'm not aware of any other program being able to create such files.

To avoid any confusion: This low overhead mode is one special version of Open-DML and is not an extention to Open-DML! Thanks to Haali for the idea to interpret the Open-DML file specification this way.