Repair a Corrupted H.264 File

H.264 (AVC) is still the most widely deployed video codec there is. It sits inside most MP4 and MOV files, inside Sony's XAVC S, and inside the raw dumps DVRs and IP cameras produce. This page is for readers who suspect their problem lives at the stream level and want to know what a recovery actually does.

The stream is usually fine. The container is not.

An H.264 bitstream is a sequence of NAL units. In a healthy MP4 or MOV they are stored length-prefixed (the AVCC layout), and the decoder configuration (the SPS and PPS parameter sets) lives in the avcC box inside the moov atom rather than in the stream. That placement is what makes an interrupted recording so destructive: lose the moov and you lose the sample tables and the decoder configuration in one shot, while megabytes of perfectly valid slice data sit untouched in mdat. Many camera encoders also repeat SPS/PPS in the stream ahead of each keyframe, which is one of the things a carving recovery leans on.

A player handed mdat without moov will not even try to parse the payload. Without sample tables it has no idea where a frame begins, so it reports "moov atom not found" or a generic open failure and gives up.

Raw-stream carving, and why "no reference" matters

The classic free tool for this failure is untrunc, which has earned its reputation, though it repairs by example. You hand it the damaged file together with a healthy one from the very camera and recording mode that produced it, and it maps the intact file's structure onto the broken one. Whether that helps you depends entirely on whether you can produce that second file. Our engine takes the other route and reconstructs everything from the broken file alone:

• Frame boundary detection. The carve scans the payload for NAL unit boundaries, in both Annex-B form (00 00 00 01 start codes) and the length-prefixed form MP4/MOV use, and classifies each NAL by type: parameter set, IDR, non-IDR slice.
• Codec parameters from the stream itself. Resolution, profile, level and frame timing are read from the parameter sets and slices the carve observes, not from a template.
• Tolerance for damage. Garbage between valid frames is skipped rather than treated as fatal, which matters for files that came back from disk-level data recovery.
• Composition timing rebuilt. A raw H.264 stream carries frames in decode order. When B-frames are present, a naive remux gives every frame pts = dts, and strict players (QuickTime especially) show juddering back-and-forth motion. The rebuild restores presentation timing, so the recovered file plays in the picky players and not only in FFmpeg-based ones.
• Audio carved alongside. AAC and PCM tracks are detected and rebuilt into the new container in sync with the video.

Free checks worth your time

1. ffprobe -v error broken.mp4. "moov atom not found" means container loss with likely intact stream data, the best case for carving; see moov atom not found. "Invalid data found when processing input" is broader; see that error's page.
2. If you have a bare elementary stream (a .h264 / .264 dump from a DVR or IP camera) rather than a broken MP4, try wrapping it: ffmpeg -f h264 -i dump.h264 -c copy wrapped.mp4. DVR dumps are usually Annex-B with in-stream parameter sets, and when the stream is clean that one-liner is all you need.
3. VLC. It plays some structurally damaged files QuickTime refuses. If VLC plays the whole file, you may not need a repair at all.
4. untrunc, if you do have a reference clip from the same camera and mode.

FFmpeg deserves a note of its own. It is superb at remuxing parseable input, but it has no carve mode for the mdat blob inside a broken MP4; it needs a readable container or a clean, self-describing stream. That gap is where this engine lives. The longer comparison is at FFmpeg and Shutter Encoder vs recovery.

What recovery does not do

No re-encoding. Slices are copied bit for bit into the rebuilt container, so there is no generation loss. No decryption either: DRM-protected or encrypted streams are out of scope for any repair tool, ours included. And no guesses billed as results. The free preview is decoded from your actual recovered stream, so you see real frames before deciding anything.

What you do

1. Upload the file. A broken MP4/MOV or a raw dump, up to 50 GB.
2. A free 5-second preview about a minute later.
3. Pay from $5 if it shows your footage. Nothing recovered, nothing owed.

FAQ

How do I know whether my file is H.264 or H.265? ffprobe reports codec_name=h264 or hevc when the container is readable. When it is not, the engine detects the codec from the frame data itself, so you do not need to know before uploading. If yours turns out to be HEVC, the process is the same; see recover HEVC files.

Can you repair a raw .h264 dump from a DVR or IP camera? The engine works at the stream level, so container-less dumps go through the same carve. Try the free FFmpeg wrap above first; if the stream has damage FFmpeg trips on, upload it and the preview will show whether the carve gets further.

Will the recovered file be re-encoded? No. The original slices are preserved exactly. Only the container around them is new.

A file I repaired elsewhere plays with shaky, back-and-forth motion. Why? That is the B-frame timing problem described above: the file was rebuilt with decode timestamps only. A correct rebuild restores composition timestamps. The free preview lets you check for this before paying anyone.

Does H.264 inside other containers work, like MXF? MP4, MOV, MXF and insv containers are all supported. For anything more exotic, the free preview is the quickest way to find out whether your specific file carves.

Is my footage private? Server in France, auto-deleted after 48 hours, never shared or used for training.

Related

• Recover HEVC / H.265 files
• Moov atom not found
• FFmpeg and Shutter Encoder vs recovery
• How the recovery engine works

Upload your H.264 file →