A file that is the right size but reports a duration of 0:00 is almost never damaged video. It is video with no index, and moov atom missing repair is the process of rebuilding that index rather than recovering the frames. The frames are usually all there. What is missing is a small table of offsets that tells the player where each frame begins and how long it lasts.
That distinction decides everything that follows. Because the payload is intact, the repair is structural, not reconstructive: a healthy file from the same camera is used as a template, and the broken file’s own video samples are re-indexed against it. Nothing is re-encoded, so there is no quality loss. Before starting, copy the broken file to a working drive and never edit the original in place.
The Symptom That Identifies This Specific Problem
Several failure modes produce an unplayable video, and they need different fixes. Narrowing it down first saves a lot of wasted effort. The reference-file method described here applies to exactly one row of the table below.
| What you see | What it usually means | Does the reference method apply? |
|---|---|---|
| Normal file size, duration 0:00, will not open | Index atom missing or damaged; payload intact | Yes |
| 0 bytes or a few kilobytes | Payload never written; no video to repair | No |
| Plays but stops partway, duration shorter than expected | File was truncated during write | Partly; the surviving portion can often be repaired |
| Plays with gray or green blocks throughout | Bitstream damage inside the video data | No; the payload itself is damaged |
| Only the last chapter of a set is broken | Interrupted recording in a chaptered set | Yes, for that chapter alone |
| Opens in one player, not another | Codec or container support issue, not damage | No |
The first row is by far the most common outcome of a power loss, a battery pull, or a camera shutdown during recording, because of where the index lives in the file. The mechanism behind the interruption itself is described under a recording that lost power.
What the moov Atom Is and Why It Ends Up Missing
An MP4-family file is a tree of boxes, called atoms. Two matter here. The mdat atom holds the encoded video and audio samples and is almost the entire file. The moov atom holds the index: for each stream, the sample table that maps a presentation time to a byte offset, the time-to-sample table, the sync-sample table that identifies keyframes, and the stream parameters a decoder needs.
The sample table is why a player can seek. Without it, a decoder would have to guess where each frame starts, and no player is willing to guess, so a file with no usable moov is reported as unreadable or as zero length even though mdat may be gigabytes.
The critical detail is write order. Many cameras and action cameras write mdat first and append moov when recording stops, because the index cannot be finalized until the last sample has been written and its size and duration are known. A clean stop writes the atom. A power cut during recording means the atom is never written at all, or is written partially. Either way, the index is gone and the payload is not. This is also why the same interruption pattern appears across brands and models: it is a property of the container, not a defect in one camera. The container-level picture is covered in how container formats work.
Some cameras write moov at the start instead, a layout usually called faststart, which trades a slower finalization step for a file that is streamable immediately. Those files fail differently under interruption: they may open and play a fraction of a second before stopping, because the index exists but points at samples that were never written. That is the third row of the table above, and it is a truncation problem rather than an index problem.
Why the Video Data Is Fine and Only the Map Is Gone
This is the counterintuitive core of the page. An index atom for a long recording is frequently only tens or hundreds of kilobytes, while the recording it describes can be several gigabytes. Losing a few hundred kilobytes therefore costs you nothing in image quality. It costs you the ability to navigate the file.
Two practical consequences follow. First, a tool that rebuilds the index does not need to touch the encoded video at all, which is why a successful repair preserves the original quality exactly rather than approximately. Second, the repair can often produce a completely usable file even when the original index was never written, because the required information can be inferred from a structurally identical file.
The information the repair borrows is the shape of the sample table: the codec parameters, the frame rate, the resolution, the number of streams, and the typical sample pattern. Those are identical for every clip recorded by the same camera in the same mode. What the repair does not borrow is anyone else’s pixels.
For chaptered recordings, this has a useful side effect. Because each chapter is a self-contained file with its own index, an interruption damages only the chapter that was open — typically the last one. Everything before it is already complete and indexable. That pattern is described in chaptered GoPro recordings.
How the Reference-File Method Works
The tool most commonly used for this repair is untrunc, an open-source utility originally written for exactly this failure mode. Its approach is comparative rather than analytical: it reads the healthy reference file, learns the structure of its index, then walks the damaged file’s mdat and rebuilds an equivalent index for it.
A good reference file must match the broken file closely. It should come from the same camera, the same recording mode, the same resolution and frame rate, and ideally the same codec profile. A clip from a different model, or from the same camera in a different mode, may have a different number of streams or different sample timing, and the repaired file will then have wrong durations, out-of-sync audio, or no audio at all. If you have a clip recorded minutes earlier in the same mode, that is the ideal reference.
Two things make this method unusually effective. It requires no knowledge of the file’s contents beyond the reference, and it works on the file as it sits on disk, so it can be attempted on a recovered file before anything else is tried. If the file itself has not yet been recovered from the card, start with recovering camera video and come back to the repair afterward.
Running the Repair: A Complete Walkthrough
Work on copies. Nothing in this procedure requires modifying the original, and keeping it untouched means a failed attempt costs nothing.
- Collect a reference file. Find a clip from the same camera and the same recording mode that plays correctly. Smaller is fine; a ten-second clip is enough. Keep it on the same drive as the broken file so the tool does not choke on a path with different permissions.
- Copy the broken file to a working folder. Rename the copy to something short and without spaces or non-ASCII characters, such as
broken.mp4. Long paths and special characters cause more failures in this tooling than anything else. - Install
untrunc. It is available as a binary for Windows, macOS, and Linux from its project releases. On Windows, unpack it and run it from a command prompt in the folder holding your files. - Run the repair with the reference first. The convention is healthy file first, damaged file second:
“ untrunc reference.mp4 broken.mp4 “
Depending on the build, the tool may accept a save-state flag such as -s to write progress to a file, which is useful for very large recordings since the walk can take a long time on a multi-gigabyte file.
- Wait. The tool reads through the
mdatsamples and constructs the index. Expect minutes for a short clip and considerably longer for a large one. Interrupting it produces a partial index, which plays but stops early. - Find the output. A successful run writes a repaired file, commonly named
broken_fixed.mp4, in the same folder. - Test before trusting. Open the output, check its duration against the expected length, scrub the whole timeline, and confirm audio is present and in sync.
If untrunc reports that it cannot parse the reference index, the reference is structurally different — usually a different codec profile or a different number of audio streams. Try another clip. If it parses the reference but produces a file with a wildly wrong duration, the reference frame rate probably differs from the broken file’s.
Where the goal is simply to make a partially readable file playable without rebuilding the index, a container-level remux with ffmpeg -i broken.mp4 -c copy -movflags +faststart output.mp4 can sometimes succeed, particularly when the index is present but at the end of a truncated file. It is a weaker fix than a rebuilt index and it is covered in the broader workflow for repairing corrupted video files.
When the Reference Method Fails
Three situations defeat this approach, and recognizing them early avoids hours of confusion.
The first is a genuinely truncated file. If recording stopped before the last sample was fully written, the repaired index will describe samples that are incomplete or absent. The repair still helps — it usually recovers most of the recording — but the last few seconds will not decode, and no index can invent frames that were never written.
The second is a file whose payload is damaged rather than merely unindexed. Gray or green blocks scattered through the footage, or a file that will not decode even with a rebuilt index, indicate bitstream damage. That is a different problem requiring a different class of repair, described under recovered files that will not open.
The third is encrypted or proprietary containers where the sample table depends on a key or a proprietary layout. Nothing in the reference method applies, and the footage must go back through the platform that produced it.
A related but separate case is a recording that was interrupted and then the card was reused. If the new footage overwrote the blocks that held the unindexed clip, no repair will help, because the payload itself is gone. That is the boundary described under when data is unrecoverable.
If you are on Windows and the card is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive.
Frequently Asked Questions
How do I know if my video is missing its moov atom?
The signature is a file with a normal or unexpectedly large size that reports a duration of 0:00 or refuses to open entirely, while other clips from the same camera play normally. If the file is 0 bytes rather than large, the payload was never written and this repair does not apply.
Can I repair a moov atom without a reference file?
Not reliably with the reference-based approach, which needs a structurally similar healthy clip to learn the index format from. Some commercial tools claim to synthesize an index from scratch, and they can work on very common camera formats. When no reference is available, try recovering a camera clip that was recorded in the same mode.
Does repairing the index reduce video quality?
No, provided you use a reference-based tool that rebuilds the index without re-encoding. The encoded video samples in the damaged file are copied as-is, and only the index that references them is written. Any tool that re-encodes the footage will reduce quality unnecessarily.
The repaired file plays but the duration is wrong. What happened?
The reference file was probably recorded at a different frame rate, resolution, or with a different number of audio streams, so the rebuilt index describes the wrong timing. Repeat the repair with a reference clip recorded in the same mode as the broken file, ideally seconds before the interruption.