Fragmented MP4: why some crashed recordings survive and some don't

The problem a normal MP4 has when a write is interrupted

An ordinary MP4 is built from boxes (also called atoms): a small ftyp up front that names the format, a largemdat holding the actual compressed frames, and amoov that is the index — the table that says which byte each frame starts at, how long it runs, and how audio stays in sync. The catch is timing: most encoders can't know the final size and position of every frame until recording ends, so they write moov last, at finalize.

A progressive MP4: the frames land in one big block, but the index that maps them is written only when recording finishes. Interrupt that ending and the map never gets written.

That is why a crash, a dead battery, or a pulled card so often produces a file that is almost entirely intact yet won't play: the frames are on disk, but the one block that explains them was never written. It is the exact failure ffmpeg reports as moov atom not found, taken apart byte by byte in MP4 anatomy. Fragmented MP4 exists, in part, to make this failure far less costly.

What fragmented MP4 does differently

A fragmented MP4 refuses to defer the index. It splits the recording into many short fragments and gives each one its own tiny index, written the moment that fragment is flushed to disk. The layout looks like this:

A fragmented MP4: a small init section declares the tracks, then the file repeats self-contained fragments, each carrying the index for the short run of video it holds.

The front of the file is the initialization section: theftyp and a moov that declares the tracks, the codecs, and the timescales, but carries empty sample tables. It says what the streams are, not where every frame sits. A specialmvex box inside it signals "expect fragments to follow."

After that comes the repeating pattern. Each fragment is amoof (movie fragment box) immediately followed by anmdat holding just that fragment's frames. Inside themoof, a track fragment run box (trun) lists the size, duration, and offset of each sample in the fragment. In other words, the map for those few seconds of video travels with those few seconds of video. A file can grow fragment by fragment and stay playable the whole time, which is exactly why adaptive streaming formats and many modern cameras and screen recorders write this way.

Why a crash costs a fragment, not the whole file

Put the two layouts side by side and the difference at the moment of a crash is stark. In a progressive MP4, interrupting the write before finalize means the single index was never written, so every frame in the file is unindexed at once — one missing block, total loss of playability. In a fragmented MP4, every fragment that reached the disk already carries its own complete index. A crash can only damage the fragment that was being written at that instant.

A crashed fragmented recording: everything up to the interruption is a run of complete, self-indexed fragments. Only the final fragment, caught mid-write, is torn.

This is the honest reason a fragmented recording tends to survive an event that would total a progressive one. It is not that the format is indestructible; it is that the damage is bounded. The blast radius of an interrupted write is a single fragment — typically a few seconds — rather than the entire timeline. If you have any control over how a long or risky recording is captured, choosing a fragmented output mode is the single most effective insurance against the classic index-lost failure, the same lesson learned the hard way inrecovering an OBS recording after a crash.

Where a fragmented MP4 still breaks

Fragmentation moves the risk; it does not abolish it. Three failure modes remain, and being honest about them is the difference between a real fix and a false promise.

A missing initialization section

The front moov is not optional. It holds the track and codec declarations every fragment relies on to be interpreted. Streaming pipelines sometimes store this "init segment" as a separate file from the media fragments, and if that init is lost, you are left with fragments whose frames can't be decoded because nothing says what codec they are or how the tracks are shaped. The frames are there; the key to reading them is not.

A torn final fragment

The fragment being written at the moment of a crash can be truncated partway through its mdat, or have a moof that never finished. Its frames are partial, so that last slice of footage is a genuine partial loss. This is the fragment repair discards rather than guesses at.

Damage inside a fragment

Bad sectors or a bit error landing in the middle of a fragment'smdat corrupt the frames stored there, exactly as they would in any container. The index is fine, but the pixels it points at are damaged, which surfaces as a glitch or freeze over that stretch and can't be regenerated. The rest of the fragments play normally.

What repair actually does with a fragmented file

Repairing a fragmented MP4 is a salvage-and-reassemble job, not a rewrite of your footage. A tool walks the file from the front, reads the initialization section for the track and codec setup, then steps through the fragments one by one, validating each moof against themdat that follows it. Every fragment that checks out is kept. A torn final fragment is dropped at the last clean boundary, and a valid file is written around the fragments that survived — without re-encoding a single frame, so quality and codec are untouched.

When the initialization moov is missing or damaged, the harder case, the track and codec parameters sometimes have to be reconstructed from what the fragments themselves declare, so the frames can be decoded again. And when a progressive MP4 is the one that lost its index, the related move is to rebuild the trailing moov from scratch by scanning the surviving stream, the technique described infixing a missing moov atom. For the wider map of what does and doesn't come back,how video files get corruptedlays out each cause.