AVI file format
Audio Video Interleave, Microsoft's classic RIFF video container.
- MIME type
- video/x-msvideo
- Extensions
- .avi
- Category
- Video
Magic-number signature
| 0x00000000 | 52494646 | RIFF | RIFF container |
| 0x00000008 | 41564920 | AVI | 'AVI ' form type |
About the AVI format
AVI is Microsoft's 1992 video container, built on RIFF — the same chunked structure as WAV, where every chunk is a four-character identifier, a little-endian 32-bit length, and that many bytes of payload. The design is simple enough to parse in a page of code, and that simplicity is the whole story: AVI has no proper concept of variable frame rate, no container-level support for modern audio, no subtitle tracks, no per-track language, and a 32-bit size field that put a hard ceiling on file length until the OpenDML extension worked around it. What it does have is a completely fixed header, because the specification requires the 'hdrl' list first and the main header chunk first inside it, so the width, height and frame rate of an AVI are always at the same byte offsets.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 4 | RIFF signature | 52 49 46 46, the ASCII letters RIFF. Shared with WAV, WebP and several other Microsoft-era formats, so on its own it identifies the chunk structure and not the format. |
| 4 | 4 | RIFF chunk size | Little-endian byte count of everything after this field — the file size minus eight. Every size in an AVI is little-endian, which is the quickest way to tell you are not looking at a QuickTime file. |
| 8 | 4 | Form type 'AVI ' | 41 56 49 20, with a trailing ASCII space that is part of the four-character code. This is the field that makes the file an AVI rather than a WAV or a WebP, and the space is why naive string comparisons miss it. |
| 12 | 4 | LIST identifier | 4C 49 53 54. RIFF groups chunks into lists, and the specification requires the header list to be the first one in the file, which is what makes every offset below predictable. |
| 16 | 4 | LIST size | Little-endian length of the header list, counting the four-character list type that follows but not these four bytes. It covers the main header and one stream header block per track. |
| 20 | 4 | List type 'hdrl' | 68 64 72 6C. Names this list as the header list. Required by the specification to come before any data, which is the opposite of MP4's arrangement and the reason a truncated AVI still reports its dimensions correctly. |
| 24 | 4 | Chunk identifier 'avih' | 61 76 69 68, the main AVI header. It has to be the first chunk inside 'hdrl', so it is always at this offset in a well-formed file. |
| 28 | 4 | avih chunk size | Little-endian, and always 38 00 00 00 — 56 bytes, the fourteen 32-bit fields that follow. Any other value here means the header has been damaged or the writer produced something non-standard. |
| 32 | 4 | Microseconds per frame | Little-endian, and the only place the frame rate is stated at the container level. 00 01 86 A0 read little-endian is 100000, which is ten frames per second. AVI has no way to express a variable rate at all, which is the format's most consequential limitation. |
| 36 | 4 | Maximum bytes per second | The peak data rate the file is expected to require, in bytes per second. It was meant to let a player decide whether the media could keep up and is effectively advisory today. |
| 40 | 4 | Padding granularity | The alignment, in bytes, that data chunks are padded to — 2048 in files written for CD-ROM playback and zero, meaning no padding, almost everywhere else. It is listed here because leaving it out puts an unexplained four-byte gap in the table. |
| 44 | 4 | Flags | A bit field: bit 4 says the file has an index chunk, bit 5 that the index should be used to determine playback order, bit 8 that the file is interleaved, bit 16 that it was captured live. The index bit is the one that matters, because without it seeking degrades to a linear scan. |
| 48 | 4 | Total frames | Little-endian frame count for the file. It is written after encoding finishes, so a recording that was interrupted leaves a zero or a stale value here and the duration a player reports is wrong even though the frames are all present. |
| 52 | 4 | Initial frames | How many frames the audio runs ahead of the video in an interleaved file. It is zero for anything not captured from a live source, and a non-zero value that a player ignores is one cause of a fixed audio offset through the whole file. |
| 56 | 4 | Stream count | How many stream header blocks follow inside 'hdrl'. Two is the ordinary case, one video and one audio; the format allows more, and old files sometimes carry a third for a text or MIDI stream that nothing decodes any more. |
| 60 | 4 | Suggested buffer size | How large a read buffer the writer thinks a player needs, in bytes, normally the size of the largest chunk in the file. Purely advisory, and commonly written as a round megabyte rather than measured. |
| 64 | 4 | Width in pixels | Little-endian. This is the container's claim about the picture size, and it is not always what the video stream itself says — a mismatch between the two is a real thing in files produced by older capture hardware. |
| 68 | 4 | Height in pixels | Little-endian, and encoded exactly like the width. Together with offset 64 these eight bytes are the fastest reliable read of an AVI's dimensions, since they sit at a fixed position in every conforming file. |
| 72 | 16 | Reserved | Four 32-bit words, all zero. They close out the 56-byte main header, so the next chunk begins at offset 88 — normally the 'strl' list holding the first stream's header. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| WAV | The same RIFF container with a different form type at offset 8: 'WAVE' (57 41 56 45) instead of 'AVI ' (41 56 49 20). Everything up to offset 7 is identical, so a check on the first four bytes tells you only that the file is RIFF. The layout after the form type diverges completely — WAV goes straight to a 'fmt ' chunk where AVI opens a 'hdrl' list. |
| WebP | Also RIFF, with 'WEBP' (57 45 42 50) at offset 8. The overlap is genuinely confusing at a glance because a hex dump of all three opens with the same four ASCII letters and a little-endian length, and only the bytes at offset 8 separate a video, an audio file and a still image. |
| Matroska | Nothing shared: Matroska begins 1A 45 DF A3 at offset 0 and uses variable-length sizes throughout. It is worth knowing the pair together because remuxing an old AVI into MKV is a lossless copy of the frames that gains variable frame rate, subtitle tracks and a proper index. |
| OpenDML AVI 2.0 | The extension that lifted the effective 2 GB and 4 GB limits. Such a file still opens 'RIFF' and 'AVI ' exactly as above, and the difference is later: extra top-level RIFF chunks whose form type is 'AVIX' rather than 'AVI ', each one continuing the stream. A reader that stops after the first RIFF chunk plays only the opening portion of a large file and reports it as short rather than broken. |
How these files break
- The idx1 index chunk is missing or truncated. It lives at the end of the file, so an interrupted download or a capture that was cut off loses it first. The video plays from the start, because the chunks themselves are self-describing, and seeking either fails outright or drops to a linear scan that takes seconds per jump.
- The 2 GB and 4 GB walls. The RIFF size field at offset 4 is 32 bits, so a writer that never emits the OpenDML AVIX extension simply wraps when the file grows past the limit. The result is well-formed and the numbers are wrong: a player reads a size far smaller than the file on disk and stops early.
- A wrong frame count at offset 48. Written when encoding finishes, so a crashed or force-quit capture leaves it at zero or at whatever the writer guessed. Every frame is present and playable, and the duration shown is nonsense — which is a header repair, not a re-encode.
- Audio and video drifting apart. AVI interleaves fixed-rate chunks, so audio encoded at a variable bitrate, which the container was never designed for, accumulates error against the video across a long file. It is inaudible in the first minute and badly out of sync by the twentieth, and nothing in the header hints at it.
- A codec nobody has any more. The four-character code in each stream header names things like DIVX, XVID, MP42 or IV50, and many of those decoders vanished with the operating systems that shipped them. The container is intact and every offset reads correctly; the file will not play because the decoder is gone, which is fixed by transcoding rather than repair.
Where the format stands today
AVI is a legacy format that refuses to disappear, and it has been the wrong choice for new work for at least fifteen years. Its limits are structural rather than incidental — constant frame rate only, no subtitle tracks, no per-track language, no modern audio, a 32-bit size field papered over by an extension — and MP4 and Matroska both fix all of them. Where you still meet it is archives: camcorder captures, screen recordings from old capture cards, video digitised from tape, and scientific and industrial cameras whose firmware was written once and never revisited. Uncompressed and lightly compressed AVI is also still used as a scratch format in a few capture pipelines, because writing a chunk and a length is about the cheapest thing a device can do in real time. For anything that needs to be kept, remuxing into Matroska copies the frames untouched and gains everything the container lacks.
Open AVI files on this site
Every one of these runs in your browser — the file never leaves your machine.
Related formats
Formats that are easy to confuse with AVI — compare their leading bytes.