Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects


Blog Archive

AVI files and common problems

I thought today I'd actually post some advice that was relevant to desktop video. But first, some commenters to my "I hate Windows" story asked for me to post my port of the Samba 4.x "editreg" tool, so here it is: I've only included the source code because the port is VERY rough and doesn't do full argument passing, and realistically you have to hack it to use it; also, it doesn't actually allow you to edit the registry, only dump its contents. Still, it works. At the time of this writing, you can get the original source code from the official Samba CVS web browser.

Now, about AVI files....

AVI stands for "Audio/Video Interleaved" and holds both audio and video together in a playable format. The basic structure of an AVI file comes from a general file structure called the Resource Interchange File Format (RIFF), which is in turn based off of the Electronic Arts IFF specification that had its roots on the Amiga. RIFF files consist of a series of chunks, each prefixed by a four-character chunk ID and a four-byte length. These chunks may in turn be nested to form a structured file. This chunk structure is nice because any unrecognized chunk can simply be skipped, allowing a file format to be extended without breaking backwards compatibility. The Portable Network Graphics (PNG) standard has an even more evolved tagging system that also encodes "should-copy" and "must-understand" bits so that old programs even have an idea of what they should do with an unrecognized chunk.

Here's what the structure of a sample AVI file looks like:

RIFF 'AVI '            Audio/Video Interleaved file
LIST 'hdrl' Header LIST
'avih' Main AVI header
LIST 'strl' Video stream LIST
'strh' Video stream header
'strf' Video format
LIST 'strl' Audio stream LIST
'strh' Audio stream header
'strf' Audio format
LIST 'movi' Main data LIST
'01wb' Audio data
'00dc' Video frame
'idx1' Index

Some notes:

If you load an AVI file into VirtualDub's hex editor, the Show RIFF Tree (Ctrl+R) command will display the RIFF tree for the file.

Overall, AVI isn't a very complex file format, and in particular it's very easy to write -- so it's not surprising that a lot of programs support it. Often AVI gets a lot of flak for not supporting a lot of newer video storage functionality, such as subtitles, timestamps, and more complex frame dependencies. Keep in mind, however, complexity has a cost, and not every file format has to, or should, support everything. The MPEG-1 file format is improved in a number of ways but is significantly more complex to support with its precise per-byte timing and bandwidth constraints and lack of a central index. In general, the more features that are put into a file format, the nicer it becomes to write and the harder it is to read... and the harder a file format is to read, the less universally it tends to be supported properly. If a file format is way too complex but still becomes popular, generally the number of incomplete and broken clients using it grows and the usable part of the file spec contracts to the part that people actually need. So file format designers beware!

Now, as for AVI files, there are a lot of mistakes that can be made in creating or transferring AVI files, and VirtualDub tries to be tolerant. Here are some of the problems I've seen:

In case it's not clear yet, VirtualDub shouldn't be used to determine that an AVI file is valid, because in the interests of compatibility and recovery it allows a number of violations. It also doesn't support a few of the lesser-used parts of the file format, most notably streams with a non-zero start time and in-stream palette changes. However, I've tried to make the parser accept most damaged AVI files and flag warnings for files that it should but can't support, to improve the usefulness of the program.

By the way... what are OpenDML AVI files?

Earlier, I said that chunks are tagged with a four-byte length. This limits the size of any chunk to ~4GB (4,294,967,295 bytes), and in fact, the practical limit is a lot lower due to compatibility concerns, around 1-2GB. The index also has the same limitation and this limits the size of standard AVI files to 2GB. A group called the OpenDML AVI M-JPEG File Format Subcommittee devised a semi-backwards-compatible way to extend this limit, by appending additional structure to a standard AVI file. The result is that legacy applications still can't read beyond 2GB, but the rest of the data is appended after the standard AVI and pointed to by a new type of two-level index. VirtualDub calls this the AVI2 format; by default it writes standard AVI files until it hits 2GB, at which point it switches to the new format.

Finally, there is one major feature of common AVI files that I haven't mentioned yet: VBR audio. In particular, I mean VBR MP3 audio. For various reasons VBR audio both is and isn't supported in the file format, and the way that it is implemented in practice is also both supported and not supported. In a future post I'll go into the technical details of how VBR MP3 audio is popularly implemented and the reasons for VirtualDub's behavior with it. I already wrote on this a long time ago, but it's a common enough question that the answer bears repeating.


This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.