AVI Held Things It Was Never Designed to Hold

The file is not the format · Long

Microsoft's 1992 container format outlived its assumptions by a decade, and every workaround left a mark.

A Container Built for a Different World

AVI — Audio Video Interleave — arrived in November 1992 as part of Microsoft's Video for Windows runtime, and the name is already a specification of sorts. The file interleaves chunks of audio and chunks of video in a predictable, alternating sequence so that a machine with limited RAM can read a little of each and play them together without buffering the whole file into memory. That design made complete sense for the hardware of the moment: 486-class processors, a few megabytes of RAM, and video that ran at 320×240 from a CD-ROM. AVI was never imagined as a vessel for two-hour films at near-broadcast quality. It was a format for small things played from slow drives.

AVI is built on the Resource Interchange File Format, RIFF, which Microsoft and IBM co-developed in 1991 as a general-purpose binary container. RIFF organises data into tagged chunks with a four-character code and a 32-bit length field — and that 32-bit length field is the first architectural ceiling, setting a hard limit of 4 GB per file. In 1992, that limit was effectively infinite. By the late 1990s, when DV cameras and high-bitrate encodes became routine, it was a real constraint. The workaround — OpenDML, a 1996 extension to the AVI specification written by Matrox and later published as the OpenDML AVI File Format Extensions — grafted an 'AVI2' superindex structure onto the original format to allow multi-gigabyte files. It worked well enough that software generally hid the seam, but it was an extension bolted to the outside of a fixed specification, not a redesign. Every large AVI you have ever played was quietly relying on an afterthought.

What Variable Bitrate Did to the Interleave

The original AVI design assumes that audio and video chunks arrive at a predictable, roughly constant rate. The index at the end of the file — the 'idx1' chunk — records the byte offset of every chunk from the start of the file, and the player uses that index to seek, to synchronise audio and video, and to maintain correct playback timing. Everything downstream depends on the audio having a known, stable frame size or a constant bitrate, because the container calculates how far apart audio chunks should be in the stream based on a fixed parameter written into the file header.

MP3 audio at a constant bitrate fits this model tolerably. Variable bitrate (VBR) MP3 does not: when the bitrate fluctuates, the audio chunks vary in size, and a naive player calculating audio position from chunk count and nominal bitrate loses synchronisation. The Xing header (later the LAME Info tag) was a workaround placed at the start of a VBR MP3 stream to give players a hint about the true duration and bitrate distribution, but the AVI container itself had no mechanism to honour it. Applications diverged. Some players ignored VBR metadata and drifted; others performed their own correction; the results depended on which software was doing the playing. AC-3, the Dolby Digital audio codec, fared even worse in AVI: the format had no defined way to carry it, and implementations differed on the codec tag and the framing, making an AC-3-in-AVI file a gamble on compatibility.

This is where codec choice and container choice became inseparable problems. The video codecs that populated AVI through the late 1990s and early 2000s — Microsoft's own MPEG-4 variants, then DivX ;-) 3.11, then the official MPEG-4 ASP encoders — were lossy codecs relying on keyframe-anchored group-of-pictures structures. A keyframe, or I-frame, stores a complete picture; the frames around it store only differences. Random access in such a stream means seeking to the nearest keyframe and decoding forward, and the idx1 index gives a player the byte locations it needs to do that. For the video side, AVI's indexing was adequate. The structural mismatch was always in the audio.

Subtitles, Chapters, and the Things That Simply Would Not Fit

AVI has no subtitle track in any native sense. The format can hold multiple audio streams — which is why dubbed foreign releases in AVI had alternate audio tracks — but text or bitmap subtitles require a track type the container never defined. The workaround was external: a separate file in SubRip (.srt) or SubStation Alpha (.ssa) format sitting alongside the AVI, with filenames matched by convention rather than by any linkage in the container. This worked until the files were separated, at which point the subtitles were gone. No chapter markers, no embedded font data, no way to flag which audio track was which language with a standardised tag. The AVI header has fields for author, title and copyright, vestigial metadata fields adequate for a 1992 multimedia clip and useless for anything that needed to be catalogued, archived or navigated.

Aspect ratio handling was another late-discovered fault. AVI stored a pixel width and a pixel height; it had no field for display aspect ratio, which meant that anamorphic encodes — pixels that are not square, designed to be stretched on playback — had to be signalled through codec-private data inside the video stream itself rather than declared at the container level. Different encoders and players handled this differently, and incorrectly-proportioned playback on some software was the predictable result.

The Editors That Made It Work Anyway

Avery Lee's VirtualDub is the tool most associated with AVI editing in this era, and the software's own development history tracks the container's shortcomings almost point by point. VirtualDub implemented its own index-repair routines for truncated or damaged AVI files, handled VBR audio interleaving with explicit control options, and eventually supported OpenDML large-file output. The fact that a single developer's tool had to build this much institutional knowledge about the container's failure modes says something about how far deployment had outrun the original specification. VirtualDub was not working around edge cases; it was managing the routine consequences of a container that had been stretched past its design.

The Moving Picture Experts Group eventually standardised what would become the MP4 container, derived partly from Apple's QuickTime format, as a purpose-built successor that understood modern audio coding, clean aspect ratio signalling, and multiple subtitle track types natively. Separately, the open-source community produced Matroska, an explicitly extensible container designed from the start to hold whatever codecs and track types a user needed, with proper chapter support, embedded subtitles, and no legacy ceiling on file size or bitrate. Both formats acknowledged, by their very existence, what AVI had failed to do. By the time streaming delivery replaced disc-based distribution entirely, AVI had effectively retired from the front line — still playable, still supported, still sitting in archive folders everywhere, but no longer anyone's first choice for anything new.

What the format's longevity actually demonstrates is not a design failure but a characteristic of file formats generally: a container that ships widely enough, early enough, acquires a gravitational field that workarounds orbit for years. AVI was everywhere before its limits were visible, and by the time those limits were obvious, the installed base was too large to abandon quickly. Every hack that kept it usable — OpenDML, the Xing VBR header, external subtitle files, codec-private aspect ratio flags — was a small tax on every user and every developer, paid continuously until something better achieved the same ubiquity.