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.
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:
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.
ffmpeg -i in.xyz -c copy out.mp4 rewraps without
quality loss. This is the case the blog command was born for.ffmpeg -i in.mp4 -c copy -t 00:12:30 out.mp4 (cut
just before the bad region).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.-movflags +faststart) — for files that already play
but start slowly on the web. It relocates an existing moov; it
cannot create one.-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.-ignore_editlist / bigger
-analyzeduration / -f mp4…"
These flags tune how ffmpeg reads valid files. None of
them synthesize missing structure.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. You pay only if we hand back a file that actually plays.
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.
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.
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.
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.
Analysis and diagnosis are free. You pay only if the repair succeeds — meaning we hand back a file verified to actually play, not just one that opens.