Container Formats Compared: What AVI, MP4 and MKV Can Each Carry

The two produce different symptoms, and separating them saves the usual cycle of installing components until something changes. A container fault stops the file being read as a file: it will not open, or it opens and seeks badly, or it lists no tracks where tracks plainly exist. A codec fault lets the file open normally and leaves one track blank, which is why silence with a good picture is never a container problem.

Container faults are also the ones that can be repaired without any new software. Rewriting the container while copying the tracks untouched takes seconds, loses nothing, and fixes malformed headers and missing indexes alike. A codec fault survives that operation completely, because nothing about the track has changed. If a rewrite made no difference, the answer was never the container.

Age explains most of the rest. AVI predates almost everything now in use and cannot store modern codecs at all, so an AVI file is usually old and its contents usually need decoders nothing ships any more. Matroska sits at the other end, able to store anything, which makes it the container where a playback failure is most likely to be about one specific track out of many. The Matroska reference covers those cases, and the diagnostic index maps a symptom onto the failing stage before anything gets installed.

The list is long because each entry answered a different question at a different moment. AVI arrived when video on a computer was a novelty and the requirement was simply to interleave one picture stream with one sound stream. It was never designed for variable frame rates, multiple language tracks or subtitles, which is why every later container looks like a reply to something AVI could not do.

MP4 came out of a standards process and inherited its priorities: broad interoperability, predictable structure, and a codec list agreed in advance. That restraint is exactly why it plays on phones, in browsers and on televisions, and exactly why it frustrates anyone who wants to attach a font or carry three subtitle formats at once. Matroska was designed from the opposite premise, that a container should refuse nothing, and it pays for that flexibility in patchy support outside computers.

The broadcast formats sit apart from all of them. A transport stream was built to be received rather than stored: it can start mid-file, survive missing data, and carry several programmes at once. Those properties are useful over the air and unhelpful on a disk, which is why recordings in that format seek poorly and are usually the first thing anyone remuxes.

Two questions settle it in almost every case. Does the file need to play on hardware that cannot be changed, such as a television, a phone or a browser? Then the answer is the restricted container with the widely implemented codec, because compatibility is the whole requirement and flexibility buys nothing. Does the file need to keep several audio tracks, styled subtitles or chapter structure? Then the permissive container is the only one that can hold them, and playback will be on a computer where support is not in doubt.

What does not work is choosing by file size, because the container contributes almost none of it. Overhead is a fraction of a percent in every format on the list; the bytes are in the tracks. A file that shrinks noticeably after a container change was re-encoded rather than remuxed, and something was lost in the process.