Container formats explained: MP4, Matroska and WebM
A container is an envelope, not a compressor. Confusing the two is the single most common source of delivery bugs, because a file extension describes the envelope while the codec identifiers inside describe the payload.
Containers solve four problems: they describe what streams exist, they index where each packet lives, they store timing information precise enough for playback, and they carry metadata that players and editors can read without decoding the media itself. Different containers solve those problems with different compromises, and the differences become visible the moment you move a file between a web player, a broadcast workflow and an editing suite.
MP4: the interchange workhorse
The ISO Base Media File Format, and MP4 as its most widely deployed profile, stores media in a tree of typed boxes. A moov box holds the track descriptions, a sample table maps presentation timestamps to byte offsets, and the mdat region holds the actual packets. Because the index is a random-access structure, a player can seek without scanning the whole file, provided the moov box arrives early enough. For network delivery, moving the index to the front of the file turns a slow first frame into an immediate one.
MP4 is restrictive in useful ways. It has one canonical way to describe a track, which is why consumer televisions, set-top boxes and phones nearly all accept it. It also has well-defined support for fragmented operation, where the file is written in self-contained segments that can be produced live and stitched later. That combination of ubiquity and streaming support is why MP4 remains the default delivery container for on-demand video.
Matroska: maximum flexibility
Matroska is an EBML-based container designed to hold almost anything without dictating how. Multiple video, audio and subtitle tracks coexist as first-class citizens. Chapters, attachments and arbitrary metadata tags are native rather than bolted on. Its index, the cues element, can describe sparse keyframe positions, so seeking in a long recording stays fast even when the file is enormous.
That permissiveness is exactly why Matroska is the natural archive format for multi-language masters. The cost is compatibility: consumer hardware support is thinner, so a Matroska file frequently needs repackaging before it reaches a living-room device. Nothing about the compression changes during that repackaging, which is the instructive point. Container conversion can be lossless when the underlying codec is untouched, because only the envelope is rewritten.
WebM: a constrained subset for the web
WebM is a profile of Matroska that narrows the allowed codecs, historically VP8 and VP9 and, in current practice, also AV1. The narrowness is the feature. A browser that announces WebM support knows exactly which decoders it must provide, and authors get a predictable target. For progressive playback on the open web, the WebM profile and the fragmented MP4 profile are the two realistic choices, and both are supported by the modern media element without plugins.
Practical comparison
| Property | MP4 (ISOBMFF) | Matroska | WebM |
|---|---|---|---|
| Index model | sample table in moov | cues (EBML) | cues (subset) |
| Track count | many, canonical | unlimited | limited |
| Chapters and tags | supported | native, rich | minimal |
| Streaming form | fragmented MP4 | live EBML clusters | fragmented WebM |
| Consumer device support | broadest | hardware-dependent | web-first |
| Typical role | on-demand delivery | archive and mastering | open web playback |
Timestamps, edit lists and the classic drift bug
Audio and video rarely start at exactly the same instant in the source. Containers express that offset either through an edit list or through an initial timestamp gap. When a pipeline ignores the edit list during a remux, the result plays with an audio lead or lag that looks like a decoder fault but is really a metadata omission. Checking the start-time fields before and after a remux is a cheap habit that prevents an expensive misdiagnosis.
Colour metadata travels the same road. Transfer characteristics, primaries and matrix coefficients are stored as container-level descriptions that reference the payload. A remux that drops those boxes can turn a correctly graded HDR production into a washed-out or over-bright playback without touching a single compressed byte. Preserving descriptive metadata is therefore part of any responsible container operation.
Summary
Containers organise streams, index them, time them and describe them. MP4 optimises for universal acceptance and structured delivery, Matroska optimises for flexibility and archival richness, and WebM optimises for predictable web playback. Selecting among them is a compatibility and operations exercise, entirely separate from the compression choices covered in the codec architecture module.