Why a corrupted video stops after two seconds

A damaged video behaves differently from a damaged document, and the difference confuses people. Sometimes it refuses to open. Sometimes it plays for two seconds and stops. Sometimes it plays through with a burst of blocky garbage in the middle. All three come from the same structure.

MP4 is a tree of boxes

An MP4 file, formally ISO Base Media File Format, is a sequence of boxes (also called atoms). Each begins with a 32-bit size and a four-character type, and boxes nest.

The three that matter:

• ftyp declares the brand, for example isom or mp42. It is normally the first box in the file.
• mdat is the media data: the actual compressed audio and video, usually the overwhelming majority of the bytes.
• moov is the index. It contains no media at all.

What is inside moov

The moov box holds a track for each stream, and inside each track a sample table made of several boxes with unmemorable names:

• stsd describes the codec and its configuration
• stts maps sample numbers to durations
• stsc maps samples to chunks
• stsz records the size of every sample
• stco or co64 records the byte offset of every chunk

Together these say: frame 4,912 starts at byte 41,220,608, is 9,344 bytes long, and is displayed at 03:16.4. Without them the player is holding several hundred megabytes of compressed data with no idea where any frame begins.

That is the whole answer to “why did the video stop”. It did not run out of data. It ran out of index.

Where moov sits, and why it matters

By default many encoders write mdat first and moov last, because the sizes of every sample are only known once encoding finishes. That is fine for a local file, and terrible for streaming: a browser must download the entire file before it can play a second of it.

The fix is faststart, which moves moov to the front after encoding, so a progressive download can begin playing immediately. If you have ever run ffmpeg -movflags +faststart, that is what it does.

This has a direct consequence for damage. If moov is at the end and the file is truncated, you have every frame and no way to locate them. If moov is at the front and the tail is truncated, a player can often play the portion it has, because the index for the early samples is intact and the offsets are valid up to the point where the data stops. That is the two-second playback case.

The partial-glitch case

The third behaviour, playing through with a burst of blocks, is different again. There the index is fine and the damage is inside mdat. Modern codecs encode most frames as differences from earlier ones, so a corrupted P-frame or B-frame propagates visually until the next keyframe resets the picture. The player never errors; it just renders wrong for a while.

Removing keyframes deliberately is the basis of the datamosh effect, covered in datamosh, pixel sorting and databending.

Matroska does it differently

MKV and WebM use EBML, a tagged binary structure that is more like XML than a box tree. Timing information is distributed through the file rather than concentrated in one index, with a Cues element as an optional seek aid. The practical effect is that Matroska tolerates truncation better: a partially downloaded MKV frequently plays up to the cut. It is a good format to keep in mind when you need a video that degrades rather than dies.

Breaking a video on purpose

If you need a video file that no player will open, the target is not the media data. It is:

• the ftyp brand, so the container type cannot be established
• the whole moov atom, including every sample table box
• entropy scattered through mdat, so frame carving recovers nothing

That is what the video corrupter does, and it is why the output shows no duration and no resolution in a file manager while still occupying exactly the same number of bytes. If you would like to compare the failure modes, damage a video deliberately at Light and at Standard and watch the difference between a glitch and a dead file.

The same index-versus-payload distinction runs through how a PDF finds its own pages, which is worth reading if you want the document-format version of the same idea.