The moov atom, explained simply

What it is

Think of an MP4 as a book with no page numbers and an index at the back. The pages (the “mdat”) hold your video. The index (the “moov”) says which frame is on which page, how long each lasts, and which track it belongs to. Players read the index first. No index means they can’t even begin.

Why it goes missing

Cameras write the index last, after you press stop, because only then do they know the full list of frames. If the battery dies, the app crashes, the card fills up, or someone pulls the card, the index never gets written. You’re left with a full-size file that’s all pages and no index.

It can also go missing when a file is cut off during transfer and the index was at the end.

Moov at the start vs the end

Files with moov at the end can’t start playing online until the whole file has downloaded. “Faststart” (ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4) moves it to the front. It’s a common fix for videos that won’t stream or seek on websites. We wrote about why moov at the end breaks streaming.

Rebuilding a missing moov

Since the frames are still there, the index can be rebuilt by scanning the data and recognizing where each frame starts. That’s much easier and more accurate with a reference: a short, healthy clip from the same camera with the same settings. untrunc does this, and our untrunc reference guide and FFmpeg moov fix guide walk through it.

Or open it in FixCorruptVideo. You can attach a reference clip, and you’ll see a free preview before you pay.

Atoms, boxes, and why the names are confusing

Apple called the building blocks of QuickTime files “atoms” in the early 1990s. When MP4 was standardized from QuickTime’s design, the spec renamed them “boxes”. Same thing, two names. You’ll see both in error messages, forums, and tools, so don’t let that throw you.

Every box starts with eight bytes: four for its size and four for its type, written as letters like ftyp, moov, or mdat. A player reads those eight bytes, knows how big the box is, and either opens it or skips over it. That simple layout is what makes MP4 flexible, and also why one missing box can make a whole file unreadable.

What lives inside moov

Inside moov there’s a header (mvhd) with the overall duration and timescale, and one trak box per track: usually one video and one audio, sometimes more for timecode, metadata, or GoPro-style sensor data.

Each track has a sample table (stbl), which is the heart of the whole thing. It lists the size of every frame (stsz), where chunks of frames start in the file (stco or co64 for big files), how long each frame lasts (stts), which frames are keyframes you can seek to (stss), and the codec setup data (stsd) the decoder needs before it can show anything. For H.264 that setup lives in an avcC record; for HEVC it’s hvcC.

So when people say the moov atom is missing, they mean all of this is missing: the frame list, the timing, the seek points, and the codec setup. The frames themselves are still in mdat, but nothing describes them.

Why moov goes missing

Most cameras can’t know how many frames a recording will have until it ends, so they write moov last. If recording is interrupted, by power loss, a full card, a thermal shutdown, a crash, or a card pulled too early, moov never gets written. This is by far the most common cause.

A copy or download that stops early is the second cause. If moov was at the end of the file (the default for most cameras), cutting off the last few megabytes takes moov with it, even if 99% of the video arrived.

Less often, a file recovered with undelete software has its parts stitched together from the wrong places on the card. The moov might be there but point at the wrong data, or the beginning of the file belongs to a different clip entirely.

How to check whether moov is present

Easiest: ffprobe broken.mp4. If you see “moov atom not found”, it’s missing or unreadable. If ffprobe prints stream information, it’s there.

If you want to look yourself, a free tool like MP4Box (MP4Box -info broken.mp4) or an online MP4 box viewer will list the top-level boxes. A healthy camera file usually shows ftyp, then mdat, then moov, or ftyp, moov, mdat if it was optimized for streaming. A broken one shows ftyp and mdat, and then nothing.

You can also check in a hex editor: search for the text “moov” near the end of the file. Not finding it isn’t absolute proof, but combined with the error message it’s a strong sign.

Rebuilding moov: how it actually works

To rebuild the index, a repair tool reads through mdat and finds where each frame starts and ends. Compressed video has recognizable patterns: H.264 and HEVC frames are made of units with predictable headers, and AAC audio frames have their own structure. Step through the data, identify each unit, and you can rebuild the frame list.

The hard part is the codec setup data. It was supposed to be in moov, so it’s gone too. That’s where a reference file helps: a healthy clip from the same camera at the same settings carries an identical setup record. Copy it over and the decoder can read the broken file’s frames.

Timing is reconstructed from the frame rate, and audio is interleaved by matching chunk patterns. Our server-side engine does all of this natively for H.264, HEVC, and AAC before falling back to untrunc, then remuxes the result so it plays everywhere. That’s also why we ask for a reference clip when one would make the difference: it isn’t upselling, it’s the missing ingredient.

Faststart: moving moov to the front

Even when moov is perfectly fine, its position matters. If it’s at the end, a web browser has to download the whole file, or make a separate request to the end, before it can start playing. Streaming sites and social apps prefer it at the front.

Moving it is lossless and quick: ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4. If a video plays on your computer but loads slowly or not at all when uploaded to a website, this is usually the fix.

Formats that avoid the problem

Fragmented MP4 writes many small index pieces as it records, instead of one big moov at the end. If recording stops, you lose at most the last fragment. Many newer cameras and phones use it for long recordings, and it’s what streaming services use.

MKV (Matroska) is similarly tolerant, which is why OBS recommends it. Professional cameras often use MXF or record to formats with frequent index writes for the same reason.

If your device lets you choose, pick one of these for anything long or important. You can convert to a regular MP4 afterward without losing quality.

What lives inside moov

The moov box is a folder of smaller boxes. At the top is mvhd, the movie header, which stores the overall timescale and duration. Under it is one trak box per track: usually one for video, one for audio, sometimes more for timecode, metadata, or a second audio language.

Each trak holds a mdia box, and inside that a minf box, and inside that the stbl box, the sample table. The sample table is the part that actually matters for playback. It is a set of lists that together describe every frame in the track.

stsd describes the codec and carries its setup data, for example the SPS and PPS for H.264 or the VPS, SPS, and PPS for HEVC. Without this, a decoder cannot interpret a single frame, even if the frames themselves are perfect. stts lists how long each frame lasts. stsz lists the size of each frame in bytes. stco or co64 lists where each chunk of frames starts in the file. stsc says how many frames are in each chunk. stss lists which frames are keyframes, so players can seek.

Lose any one of these and playback breaks in a specific way. Lose stss and seeking becomes slow or jumpy. Lose stts and timing drifts. Lose stco and the player reads garbage. Lose stsd and nothing decodes at all.

Why moov can’t simply be guessed

Rebuilding moov means reconstructing all of those tables by reading the raw mdat data. That sounds easy until you remember that mdat has no markers saying where one frame ends and the next begins. Video and audio are interleaved in chunks, and the chunk sizes vary from camera to camera.

For H.264 and HEVC, the video frames are stored with a length prefix, usually four bytes, followed by the encoded slice. A repair tool walks through mdat, reads a length, checks that the bytes after it look like a valid slice header, and moves on. When it hits something that doesn’t parse as video, it has to decide whether that is an audio chunk, padding, or damage.

Audio is harder. AAC frames in MP4 have no length prefix and no sync word, so the tool has to infer their boundaries from the gaps between video chunks and from the bitrate. This is why a reference file from the same device helps so much: it shows exactly how that camera interleaves audio and video, how big its audio chunks tend to be, and what its codec settings are.

The setup data in stsd is the other reason a reference helps. Some cameras repeat SPS and PPS inside the stream so they can be recovered; others only store them in moov. If they only live in moov and moov is gone, the only practical way to get them back is to copy them from a healthy clip recorded with the same settings.

Fragmented MP4: a different design

Some devices and most live-streaming software avoid the whole problem by writing fragmented MP4. Instead of one big moov at the end, they write a small moov at the start that describes the tracks but lists no frames, then a series of moof and mdat pairs. Each moof is a mini index for the fragment that follows it.

If recording stops abruptly, you lose at most the last fragment, usually a second or two. Everything before it is already indexed. OBS offers this as a recording option, and many recent phones and action cameras use it or something similar for exactly this reason.

The catch is compatibility. Some editors and older players handle fragmented files poorly, so it is common to remux them into a regular MP4 after recording. That remux is lossless and takes seconds: ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4.

Moov at the start versus the end

A healthy MP4 can have moov either before or after mdat. Cameras put it at the end because they don’t know the frame list until recording stops. Web video is usually remuxed so moov comes first, which lets a browser start playing before the whole file downloads. This is what the faststart flag does.

When a file plays locally but stalls in a browser or a streaming app, a moov at the end is a common reason. The player has to fetch the end of the file before it can start. Moving moov to the front fixes it without touching the footage.

When moov is missing entirely, its position doesn’t matter, because there is nothing to move. That is the case where you need a rebuild rather than a remux.

Inspecting the boxes yourself

You don’t need special software to see the structure. ffprobe -v trace file.mp4 2>&1 | grep -E "type:'(ftyp|moov|mdat|free|moof)'" prints each top-level box as FFmpeg finds it, with offsets and sizes. A healthy camera file shows ftyp, then mdat, then moov. A broken one usually shows ftyp and mdat and then stops.

MP4Box from GPAC (MP4Box -info file.mp4) gives a friendlier summary of tracks and codecs. Online box viewers exist too, but avoid uploading private footage to unknown sites just to look at its headers.

One quick sanity check: compare the mdat size reported by the trace with the total file size. If mdat claims to be larger than the file, the recording was cut short. If mdat has a size of zero or one, the camera never went back to fill in the size, which is another sign it stopped before finishing.

When to rebuild it yourself and when not to

If you are comfortable with a terminal, untrunc and similar tools rebuild moov from a reference file and work well for common phone and camera formats. They struggle with unusual audio codecs, variable frame rate, and files from devices they have never seen.

Our engine does the same job server-side with a frame scanner that recognises H.264, HEVC, and AAC structure directly, and falls back to reference-based rebuilding when needed. If you’d rather skip the command line, open the file on the repair page. You get a free 15-second preview of the repaired clip before paying anything, and if it looks right you can unlock the full file for $9/month or $29/year.