"No Valid MP4 Found" — How to Recover the File

This error — sometimes "no valid MP4 found," "not a valid MP4 file," "file is not in a recognised format," or "no atoms found" — comes from a parser that opened your file, looked at the first chunk of bytes, and concluded it isn't an MP4 at all.

That's a stronger statement than "MP4 with a missing index." The parser isn't even confident it's looking at an MP4. Three things might be happening.

Cause 1: the ftyp atom is missing or damaged

Every MP4 / MOV file starts with an ftyp atom — a small (usually 32-byte) header that identifies the file as MP4 / MOV and declares the format brand. If those first bytes are damaged or missing — overwritten, never written, lost in a partial file copy — the parser doesn't see "MP4" and bails.

This often happens when:

• A file was partially copied off an SD card before the copy completed.
• The first sector of the file got hit by a filesystem error.
• A previous recovery attempt with an unreliable tool stripped the header.

Cause 2: the file actually isn't an MP4

It might be a:

• Renamed .mkv (MKV files start with 1A 45 DF A3 — completely different).
• Renamed .avi (RIFF-format header).
• Raw .h264 / .h265 elementary stream that someone gave a .mp4 extension.
• ProRes raw stream without a container.

Test:

file your_file.mp4

If file reports anything other than ISO Media, MP4 ..., it's not actually an MP4.

Cause 3: the file is mdat-only — no container at all

Some recovery attempts (or some camera failure modes) produce a file that's just the raw mdat payload with no ftyp and no MOOV — just compressed video frames sitting in a file. The parser sees no atom signatures at all and gives up.

This is recoverable but requires building a complete container around the data, not just rebuilding the index.

How to figure out which one

file your_file.mp4
xxd your_file.mp4 | head -1

Read the first 16 bytes:

• Starts with ... ftyp ... somewhere in bytes 4–12 → cause 1 with partial damage; ftyp should be at byte 4 but might have shifted.
• Starts with 1A 45 DF A3 → it's actually MKV.
• Starts with 52 49 46 46 (RIFF) → it's actually AVI / WAV / WebP.
• Starts with 00 00 00 01 or 00 00 01 → it's a raw H.264 / H.265 stream.
• Starts with icpf (or close to it in the first chunk) → raw ProRes frames.
• Starts with random-looking bytes → cause 3 (mdat-only) or deep corruption.

ffprobe -v error your_file.mp4

If ffprobe returns useful information about streams despite the error, the file is more recoverable than it looks.

What you can try yourself

For cause 1 — partial header damage

ffmpeg -err_detect ignore_err -i broken.mp4 -c copy out.mp4

Sometimes works if ftyp is partially intact and FFmpeg can find atoms past the damage.

For cause 2 — renamed file

Rename to the actual format and play normally:

mv broken.mp4 broken.mkv

For cause 3 — mdat-only

This is the harder case and needs frame-level analysis to identify the codec, then container construction from scratch. This is exactly what our pipeline does.

How our recovery handles it

• Byte-level scan of the first MB of the file looking for ftyp, atom signatures, and codec-specific frame markers.
• Codec identification from frame data — works even when no container metadata exists (cause 3).
• Container synthesis from scratch when needed: we build a fresh MP4 wrapper around the identified frames.
• Format recognition for the renamed-file cases — the diagnostic identifies the actual format and either repairs the original or tells you to rename.

For cause 3 in particular, this is one of the harder recovery scenarios — we're effectively building a container around raw codec data — but it's tractable when the codec is one we recognise (ProRes, H.264, H.265, MJPEG).

What you do

1. Upload the file. Up to 50 GB.
2. The diagnostic identifies which cause applies and what's recoverable.
3. If recovery is possible, you preview, pay only if it works.

FAQ

The file is exactly the size I expect from a recording, so why isn't it an MP4? File size is unrelated to format. A file can be the right size and have entirely wrong header bytes (overwritten, never written, scrambled by a botched conversion). Check the actual content with file and xxd.

A previous recovery tool wrote a "fixed" file that produces this error. Common. Some tools strip or modify the ftyp in ways that break compatibility. If you still have the original file (before the bad recovery), work on that. If not, upload what you have — we can usually rebuild even from a partially-mangled output.

My camera produced this error directly off the SD card. Possible if the camera died very early in the recording, before ftyp was even written. Less common than a missing MOOV, but it happens. Upload it.

Will this work on raw .h264 / .h265 elementary streams? Yes — we wrap them in a valid MP4 / MOV container. Frame timing has to be inferred (no timestamps in elementary streams), so the result plays at a default frame rate; you can adjust with FFmpeg afterwards if needed.

Is my footage safe? Server in France, auto-deleted after 48 hours, never used to train anything or shared. Privacy policy.

Related

• MOOV atom not found
• Invalid data found when processing input
• How our recovery engine works

Upload your file →