Can ffmpeg fix a corrupted MP4? An honest map of what works

Search for "fix corrupted mp4" and every blog hands you the same command: ffmpeg -i broken.mp4 -c copy fixed.mp4. Sometimes it works instantly. Often it fails with moov atom not found — and no amount of flag-tweaking will change that. The difference isn't luck; it's which kind of broken your file is. Here's the honest map, from people who repair the files ffmpeg can't.

The one question that decides everything

ffmpeg operates on a file through its index (the moov atom — the map of every frame's position, timestamp and codec setup). Everything ffmpeg does — copy, cut, remux, re-encode — starts by reading that map. So:

• Index intact, container or stream damaged → ffmpeg is the right free tool. Use it.
• Index missing or wrong → ffmpeg has nothing to read. No flag fixes this, because the problem is upstream of everything ffmpeg does.

Quick test: if ffmpeg -i broken.mp4 prints duration, resolution and stream info, the index exists. If it prints moov atom not found, it doesn't — see the dedicated explainer.

What ffmpeg genuinely fixes

• Wrong or mismatched container. A playable stream in a confused wrapper (mislabeled extension, an MKV a device refuses, a TS from a drone): ffmpeg -i in.xyz -c copy out.mp4 rewraps without quality loss. This is the case the blog command was born for.
• Damage near the end of an otherwise indexed file. Copying stops at the corruption; you keep the clean part: ffmpeg -i in.mp4 -c copy -t 00:12:30 out.mp4 (cut just before the bad region).
• Glitchy mid-stream damage you can tolerate. Re-encoding while ignoring decode errors (ffmpeg -err_detect ignore_err -i in.mp4 out.mp4) can produce a watchable file with artifacts at the damage — a real trade-off, not a repair: it re-encodes (quality loss) and fixes nothing structural.
• Moving the index to the front for streaming (-movflags +faststart) — for files that already play but start slowly on the web. It relocates an existing moov; it cannot create one.

The myths, and why they fail

• "-c copy repairs corruption." Stream copy reads frames via the index and writes them unchanged. With no index there is nothing to iterate; with a wrong index it faithfully copies the wrong bytes. It repairs nothing — it only rewraps what the index already describes.
• "Dump the raw H.264 and rewrap it." MP4 stores video as length-prefixed blocks with the decoder setup kept in the moov — not as a self-framing stream. With the moov gone, a raw dump has no start codes, no boundaries and no decoder parameters; players see noise. Turning that payload back into video is exactly the hard part of real recovery, not a one-liner.
• "Add -ignore_editlist / bigger -analyzeduration / -f mp4…" These flags tune how ffmpeg reads valid files. None of them synthesize missing structure.
• "VLC's built-in repair will do it." VLC's prompt fixes only one narrow case (broken AVI index). For MP4s it's the same story as ffmpeg: no index, no playback.

The honest decision guide

If your file shows its streams in ffmpeg -i: try the matching command above — it's free, lossless (except the re-encode option), and when it works you're done. If you get moov atom not found, or the "fixed" file plays seconds and dies, or video comes back without audio: the index needs to be rebuilt from the raw frames. untrunc does that for classic camera files with a matching reference clip; our engine does it for those and for the families untrunc can't handle — and always work on a copy, never your only original.

The analysis tells you which kind of broken your file is — including when a free tool would solve it, and when nothing can. Free during the beta: there is no payment step today. When paid recovery eventually launches, you will pay only if we hand back a file that actually plays.

Frequently asked questions

Why does 'ffmpeg -c copy' work for some broken videos and not others?

Stream copy reads frames through the file's index and rewraps them. If the index survived and only the container is confused, that rewrap is a genuine instant fix. If the index is missing — the usual result of an interrupted recording — there is nothing for ffmpeg to read, and no flag changes that.

Is there any ffmpeg flag that rebuilds a missing moov atom?

No. ffmpeg's flags adjust how existing structure is parsed; none of them reconstruct structure that was never written. Rebuilding an index means analyzing the raw frame data itself, which is a recovery operation outside ffmpeg's design.

ffmpeg produced a 'fixed' file but it only plays a few seconds.

That usually means the copy ran until it hit the damaged or unindexed region and stopped. The remaining footage may still be recoverable from the original file — keep the original, and upload that rather than the partial output.

Should I try ffmpeg before paying anyone?

Yes — if your file shows its stream info in 'ffmpeg -i', the free rewrap is genuinely the right first move, and if it works you're done. Just always work on a copy of the file, and if the index is missing, skip the flag-hunting: it has no ffmpeg fix.

What does it cost?

Nothing today. RepairMyVideo is free during the beta: there is no payment step, and analysis, repair and download all cost nothing. When paid recovery eventually launches, analysis and diagnosis will stay free, and payment will apply only to a successful repair, meaning a file verified to actually play, not just one that opens.