AVI File Format - The movi - Lists

The Movi - Lists contain Video, Audio, Subtitle and (secondary) index data. Those can be grouped into rec - Lists. Example:

LIST movi
LIST rec
01wb
01wb
02wb
03wb
03wb
03wb
00dc
00dc
LIST rec
01wb
02wb
LIST rec
...
...
ix01
ix02
ix03
...
...

The following chunk header IDs are defined:

• ..wb: audio chunk

• ..dc: video chunk

• ..tx: subtitle chunk

• ix..: standard index block

Grouping chunks into rec - Lists prevents excessive seeking when using the Microsoft AVI splitter for replay, but does not allow playback on some standalone replay devices.

The maximum size of a chunk of a stream should be smaller than the corresponding dwSuggestedBufferSize value. Otherwise, some players, especially the Microsoft AVI splitter, could malfunction.

Audio types requiring special attention

MP3

wFormatTag = 0x0055

An MP3 audio stream consists of inseparable frames. MP3 decoders should be able to handle partial frames, but it is nevertheless recommended to store entire MP3 frames in the AVI chunks.

The strf chunk is an MPEGLAYER3WAVEFORMAT structure, which is an extention to the WAVEFORMATEX structure:

typedef struct mpeglayer3waveformat_tag
{
WAVEFORMATEX wfx;
WORD wID;DWORD fdwFlags;
WORD nBlockSize;
WORD nFramesPerBlock;
WORD nCodecDelay;
} MPEGLAYER3WAVEFORMAT;

Important:
This is only valid for MP3 ('MPEG Layer 3'), not for MP1 or MP2 ('MPEG Layer 1 / 2').

If the MP3 stream has a variable bitrate, then you need to convince DirectShow to seekproperly.

Unfortunately, whoever came up with the idea didn't think enough about it: It is possible to create MP3 audio frames larger than 1152 bytes if the sample rate is 32 khz or less. After reading and understanding, you'll see why such audio frames render an MP3stream unplayable if nBlockSize is set to 1152, which is usually done for MP3. Using a larger value would resolve this issue. However, some programs read an MP3 stream as VBRif and only if this value is exactly 1152. In other words, low sample rates in combination with high bit rates are a problem for MP3 VBR streams in AVI files.

AC3

wFormatTag = 0x2000

Muxing AC3 into AVI is far more problematic than most other audio formats. The reason is that a lot of decoders (software as well as hardware) are severely b0rked.

An AC3 stream consists, like MP3, of individual, inseparable frames. It is required that any audio chunk of an AVI file contains a few (complete!) AC3 frames. Otherwise, someAC3 decoders will miscalculate the duration of a chunk. As the audio stream is considered the master stream for playback in DirectShow, this miscalculation will lead to jerky video playback.

Theoretically, chunks containing one AC3 frame are valid, but there are hardware decoders which won't work with such streams. If you place more than 6 AC3 frames into one chunk, you might get increased playback speed. Thus, the recommendation is to place be-tween 2 and 5 AC3 frames into one AVI chunk.

DTS

wFormatTag = 0x2001

It seems to work out to place between 2 and 20 DTS frames in one AVI chunk. I have not yet tried higher values on my own. If you have a hardware DTS decoder, please do some testing and report back what values work and which ones don't. Just like with AC3, do not split up any DTS frames.

MPx VBR

• MPEG 1 Layer 3: 1152 samples per frame

• MPEG 2 Layer 3: 576 samples per frame

• MPEG 1/2 Layer 2: Strongly discouraged from being used, because the default MPEG Layer 2 decoder present on Windows systems does not recognise MPEG Layer 2 streams when using VBR headers.

AAC

For AAC, one RAW AAC frame usually spans over 1024 samples. However, depending on the source container (e.g. ADTS), it is theoretically possible that you are not able to extract packets of equal duration from your source file. In this case, it is highly recommended not to mux the AAC stream into AVI, but report a fatal error instead.

AAC and HE-AAC require private data in the corresponding WAVEFORMATEX structures. See the source code of AVI-Mux GUI (FillASI.cpp) for details.