Video Repair: MP4, MOV and 3GP Clips That Will Not Play

About the Video Repair: MP4, MOV and 3GP Clips That Will Not Play

A camera writes a video’s index when it closes the file: the table that says where every frame is and when it is shown. When a recording stops before that — a flat battery, a card pulled out, a crash, a dashcam cutting power — the picture and sound are all still in the file and only the index is missing. Players then say “moov atom not found”, show 0:00, or refuse the file altogether.

This page rebuilds that index. It reads the healthy part of the file, finds the H.264 or HEVC frames and AAC sound frames where they already lie, takes the codec settings from the file or from a healthy clip you recorded on the same camera, and writes a new index around the original bytes. Nothing is re-encoded, so the repaired clip is exactly as sharp as what the camera recorded. Damaged WAV and MP3 recordings are fixed on the same page, the same way: by correcting what the header says, never by touching the sound. Everything runs in your browser, and nothing is uploaded.

Common uses

• Dashcam, action camera and drone clips whose recording was interrupted.
• Camera files that copied badly off a card and now stop part way through.
• Recordings found by a deep scan of a card image and marked “the video index is missing”.
• Voice recordings and field recordings whose WAV header says they are empty.
• MP3 files that stop at the same place in every player because of a damaged patch.

Why a cut-off recording will not play

In an MP4 or MOV file the picture data and the index are separate. Apple’s QuickTime File Format says of the movie atom that sample data “are referenced in the movie atom, but are not contained in it” (Apple). Cameras stream the frames straight to the card and write that index — the moov atom — only when the recording ends properly, so an interrupted file is all data and no table of contents. A player has nothing to look things up in, and reports the index as missing.

The repair puts a new table of contents in front of the same data. It never invents pictures: what the card holds is what comes back.

The three ways a file is read

• The camera’s own index. Novatek chipsets (in many dashcams) write a padding box holding an nidx index roughly once a second: the position and size of every frame and sound frame since the last one, plus the codec settings. Where these are present, every frame is verified against the real data before it goes into the new index, and entries that do not match are dropped and counted.
• The last partial second. After the final index block the structure is read forward with what the indexed part taught the page: which frame headers this camera writes, how large its frames get, how its sound frames are padded. A frame the camera was still writing when the power went is left out, because it cannot be decoded.
• A data scan. Without any index, every position that could begin a length-prefixed H.264 or HEVC picture becomes a candidate. Candidates that end exactly where another begins are almost certainly real; the page then picks the set of non-overlapping candidates that fit together best, so one nonsense length cannot swallow the real frames inside it. This finds the picture only.

What a reference clip is for

The codec settings (the sequence and picture parameter sets, and for HEVC the video parameter set) say how large the picture is, how it is coded and how it is to be displayed. Dashcams usually repeat them in the data, so nothing is needed. Action cameras, drones and most pocket cameras write them only in the index, so a cut-off file has none and no decoder can start. When a damaged file still holds its own index (a copy cut short, or an index that no longer matches the data), the settings are taken from that, and no reference is needed either.

A healthy clip recorded by the same camera, in the same mode and at the same resolution, carries exactly those settings, and the repair borrows them. It takes nothing else from the clip: no frames, no sound, no metadata. A clip from a different camera or a different resolution will produce a file that opens but looks wrong, so the report says when the settings came from your clip.

A file whose own index is complete, with every frame it lists inside the file, needs no rebuilding: the page says so instead of offering a repair.

Sound, timing and order

• Sound comes back when the camera’s index lists its frames, or when the recording is AAC in ADTS framing (each frame then carries its own length). Raw AAC inside an MP4 has no frame boundaries of its own, so after a data scan the rebuilt file has picture only, and the report says so.
• Timing. The frame rate comes from the camera’s index, from what is left of the file’s own index, from the reference clip, or from the stream itself. When none of them states one, 30 frames a second is assumed and the report says so. When the sound is there and its clock disagrees with the nominal frame rate by more than 1 % — which means the camera dropped frames — the picture timing is stretched to the sound’s clock, so the two stay together instead of drifting apart. You can also state the frame rate yourself.
• Order. Files with B-frames store pictures in a different order from the one they are shown in. The page reads each picture’s order count and writes the composition table and edit list that put them back in display order.

What the repair is measured against

The page’s automated tests build camera-style files in code and break them in the ways cameras really do: a MOV whose index was never written, a copy cut short with its index at the front, a Novatek file with its own index and extra frames after the last index block, index entries that no longer match the data, a WAV whose length fields were left at zero (with and without a recorder’s metadata chunks, and longer than 4 GB), an MP3 with junk at the start and a damaged sector in the middle, and an AAC stream with rubbish in front of it and a damaged patch inside. Each repaired file is then read back by this site’s own video validator, which parses the rebuilt index and works out how many seconds of it really lie inside the file. A rebuilt index that a player could not follow fails the tests, and so does any “repair” of a file that had nothing wrong with it.

No success rate is published for other people’s files: how much comes back depends entirely on how much of the recording reached the card.

Limitations

• Only MP4, MOV and 3GP (ISO base media) video, and WAV, MP3 and AAC sound, are rebuilt here. Matroska (.mkv), WebM, AVI and transport streams (.ts, .mts) keep their index differently and are not handled.
• An M4A (a sound-only MP4, as voice memo and music apps save) that lost its index cannot be rebuilt: the AAC frames inside it carry no length of their own. Only AAC in ADTS framing, where every frame states its length, is re-framed.
• Missing or overwritten data stays missing. If the card was reused, or the file was only partly copied, the part that is gone cannot be rebuilt — the rest still plays.
• A WAV of more than 4 GB is written as an RF64 WAV, the 64-bit form broadcast recorders use: editors such as Audacity open it, some older players do not.
• Most camera files need a healthy reference clip from the same camera: without the codec settings, no decoder can start on the data.
• After a data scan (no camera index) the rebuilt file has picture only.
• Encrypted or DRM-protected video cannot be repaired, and this page will not try.
• Nothing is invented. There is no “AI” step that paints in missing frames, and the page never claims a result it cannot show you in the preview first.
• The preview plays only where your browser and device can decode the clip. H.264 plays nearly everywhere; HEVC (H.265) playback depends on the browser, the operating system and the graphics hardware, so on some computers the report is shown and the preview says why it cannot play. The repaired file is still correct.
• A web page cannot set a file’s date, so a repaired file carries the date it was written. The recording’s own time stays inside it.

Privacy

The damaged file and the reference clip are read by your browser on your device, a few megabytes at a time; nothing from either of them is sent anywhere, and the page works offline once it has loaded.