Recovered MP4 won't play on Mac? Why, and what repair actually does

A recovered MP4 that won't play is the most common "recovery worked, file didn't" complaint we see, and it has a small number of concrete causes. None of them are mysterious. An MP4 or MOV is a container of atoms, and a player needs three of them to cooperate: `ftyp` (what kind of file this is), `moov` (the index of every frame: where it lives, how big it is, when it plays), and `mdat` (the actual compressed frames). Recovery tends to damage the first two while leaving most of the third intact. That asymmetry is why repair works at all.

This guide walks through the three failure modes you'll actually hit, how to tell which one you have, what the free tools can do, and what DataRecover Pro's repair engine rebuilds. If your problem is broader than video, why recovered files won't open covers the general case.

Most cameras and phones write `mdat` first, streaming frames to the card as they're captured, and write `moov` last, when you stop recording. If the recording was interrupted, `moov` was never written. If the file was carved from a formatted card by signature, the carver may have stopped before reaching a `moov` that sits at the end of a multi-gigabyte file. Either way the frames are on disk and the map to them is gone.

Symptom: QuickTime says the file "isn't compatible" or can't be opened. `ffmpeg -i file.mp4` (or `ffprobe`) prints "moov atom not found". The file size looks about right for the clip length.

The carve length was too short, the drive had bad sectors near the end of the file, or the copy off the drive was interrupted. `moov` may be present and pointing at frames that no longer exist. QuickTime often plays these until the bad spot and then freezes or shows a black frame; VLC tends to play through and stop. `ffprobe` reports the container fine but decoders complain about missing or invalid data near the end.

The `stco` (or 64-bit `co64`) table inside `moov` stores the absolute byte offset of every chunk of frames. Those offsets assume the file starts exactly where the camera wrote it. If a recovery tool carved the file starting a few bytes late, dropped a `free`, `wide`, or `skip` atom, or reassembled it from fragments in a slightly different order, every offset is shifted. The index is intact, the frames are intact, and they no longer line up. This is the classic "file plays as audio only" or "green and grey blocks" result.

Symptom: `ffprobe` shows correct duration, resolution and codec, but playback is garbage or silent. The `moov` atom is often before `mdat` in these files (fast-start encoded), which makes the shift more likely.

QuickTime Player is strict. It wants a valid `moov`, sane offsets and a clean end. If QuickTime plays the file, it's structurally fine. VLC is forgiving: it will scan for frames, guess timing, and play whatever it can decode. A file that plays in VLC but not QuickTime almost always has a container problem, not a data problem, which is good news because containers are rebuildable. A file that plays in neither, and in which `ffprobe` finds no `moov` and no recognizable stream, has either lost its `moov` or been overwritten.

Don't "convert" the file with VLC or HandBrake as a fix. Re-encoding a damaged input bakes the damage in and discards quality. Repair the container first, then transcode if you want to.

untrunc is a free, open-source tool that repairs MP4/MOV files with a missing `moov`. It requires a second, healthy video recorded on the same camera with the same settings (resolution, frame rate, codec). It reads the good file's `moov` as a template, then walks the damaged file's `mdat` to build a new index. Install with Homebrew (`brew install untrunc`, or build from source), then run `untrunc good.mp4 broken.mp4`. It works well when you have that reference clip and the damage is only a missing index. It doesn't fix wrong offsets on a file that already has a `moov`, doesn't handle truncation cleanly, and it can't do much without the reference file.

DataRecover Pro has a dedicated MP4/MOV repair plugin, and it escalates through specific fixes rather than one generic pass:

Header: if `ftyp` is missing or mangled, it writes a standard one. Truncation: it finds the last complete atom boundary and trims the file cleanly there, then rewrites the sample tables (`stsz`, `stsc`, `stts`, `stco`/`co64`, plus `stss` and `ctts`) so `moov` describes exactly the frames that survive. Wrong offsets: it detects the delta between where `moov` says the chunks are and where they actually begin, and rebases every `stco`/`co64` entry. Missing `moov`: it locates the `mdat` payload (even if the file starts directly at `mdat`, or `moov` was written first and lost), scans for H.264 or HEVC NAL unit chains, validates them, and builds a new container around the surviving frames. A reference clip from the same camera helps here, the way it does with untrunc, but it isn't required.

The result is written as a new file. The original is never modified. Repairs run in a sandboxed worker with no network and no write access outside its output folder, so a malformed video can't touch anything else on your Mac. You can preview the result with Quick Look before saving it anywhere. The repair page has the full tier breakdown.

1. If the video was deleted or the card was formatted, recover it again with DataRecover Pro's deep scan rather than re-using the broken copy from another tool. A carve that respects atom boundaries produces a better input than one that guesses at file length. Recover to a different drive than the source.

2. Run `ffprobe` on the recovered file to see which failure you have. "moov atom not found" is failure 1; correct metadata with broken playback is failure 3; decoder errors at the end are failure 2.

3. Let the repair engine process the file. Preview the repaired output with Quick Look. If you're seeing the frames you expected, save it. If a portion is missing, that's the portion that wasn't on the disk anymore.

Scanning, preview and repair preview are free with no account; you pay only to save. Download DataRecover Pro and check your specific file first.

Repair rebuilds structure around frames that exist. If the `mdat` region was overwritten by later recordings, the frames are gone and no tool brings them back. If the file was heavily fragmented on the card and carved as a mix of two clips, you'll get a repaired file that plays one clip's frames with the other's timing, and that needs a manual split. If the camera used a codec the moov-rebuild path doesn't understand (the NAL-chain rebuild targets H.264 and HEVC), a file with no `moov` at all will only be partially salvageable. And if the drive itself is failing, image it before you do anything else; see recover a dead or unrecognized Mac hard drive.