Audio Video Interleave

That same 4-letter slot has hosted five generations of video compression in the AVI container. Cinepak came first in 1992. Intel's Indeo took over for the mid-1990s. DivX arrived in 1999 — the codec that powered the early-2000s pirated-movie boom. Xvid followed in 2001 as the open-source alternative. H.264 took over from the mid-2000s onward. The outer container never changed across any of them. The codec identity moves; the wrapper does not. The container that hosted all of that had one stubborn limit — and the year it broke is the year half the players in the world stopped working.

Why a Generation of Movies Froze at Minute 30

A 2005-era DVD rip plays for thirty minutes, then freezes mid-shot. The seek bar reads 30:12 / unknown duration. The audio cuts. The player reports nothing wrong; the file is over but pretending it isn't. That's not a corrupt file. That's 1990s arithmetic catching up with a 2005 file.

Matroska exists because of this exact failure mode. The team that founded MKV in 2002 explicitly cited "AVI's limitations" — and the limitation they meant was the freeze a 2005 viewer was hitting at minute 30 of every long movie. Original AVI files maxed out around 2 gigabytes because of how 1990s code did the math on file sizes. The chunk-size field in the AVI header was 32 bits, but most early reader code parsed it as a signed integer — which broke at 2 GB instead of 4 GB. Many production tools enforced an even tighter 1 GB cap to ensure interoperability with the lowest common denominator. In 1996, a fix called OpenDML let AVI break past the limit by splitting the file into smaller pieces and chaining them together. The catch: any player written before 1996 read only the first piece, then stopped. That is what happened to a generation of DVD-rip viewers around minute thirty of every long movie. Files that survived the OpenDML break ran into a different problem two decades later — the devices people actually own.

The Black Box on the iPhone

A 2007 wedding video sits on someone's old hard drive — a .avi file recorded on a camcorder, never converted. They AirDrop it to their iPhone. The Files app shows the file. They tap to play. Black box. No error message, no codec-installer prompt, no path forward — just silence.

iOS Safari refuses the AVI container as a matter of policy. Not the codec inside — the wrapper itself. Apple stopped supporting Microsoft's legacy video formats years ago and has not reversed course. Smart TVs, modern Android, even Microsoft's own Clipchamp follow the same pattern: AVI is treated as a format that exists for backward compatibility, not for new content. "Convert AVI to MP4" became the dominant AVI search query of the 2020s for that exact reason. Which is the part everyone sees. The part nobody talks about is why AVI is still being written today, on purpose, in 2026.

Why Screen Recorders Still Choose AVI in 2026

OBS crashes mid-recording. Windows force-restarts. The streamer reboots, expects a useless half-file, opens the .avi anyway. It plays — every minute up to the second the recorder died, then the file ends. The MP4 from a different session on the same desktop, recorded by a different program, won't open at all.

That gap is why a class of recording tools — OBS in some configurations, older Bandicam, many security-camera DVRs, a long tail of industrial-capture systems — still defaults to AVI in 2026. AVI alternates audio and video chunks at fixed positions inside its data block. If the writer stops mid-stream, what is on disk through the last completed pair plays back. MP4 puts its index — the table that tells a player where every frame lives — at the end of the file. A half-written MP4 has no index. Without the index, the file is unreadable until a separate recovery tool reconstructs one from the partial bytes. AVI never needed that step because its index was redundant from the start: every chunk's location is implicit in the alternating layout.