"Invalid data found when processing input" — FFmpeg Video Error

This is one of FFmpeg's least-helpful error messages. It's also one of the most common. The message reads as if FFmpeg has decided your file is unrecoverable, but the underlying meaning is more specific: FFmpeg's parser hit a sequence of bytes it can't reconcile with the file format it expected.

That can mean half a dozen different things. Most of them are recoverable.

What FFmpeg is actually telling you

FFmpeg parses a file in stages. First it identifies the container (MP4, MOV, MKV, AVI, etc.). Then it reads the container's index to find streams. Then it parses individual stream packets. "Invalid data found when processing input" means a parse step failed somewhere in that pipeline. The error doesn't tell you which step.

Common underlying causes:

1. Container header is fine, codec header is damaged. FFmpeg knows it's an MP4. It reads the MOOV. It tries to start reading H.264 stream packets and finds bytes that don't match the H.264 NAL syntax. The codec parameter set is corrupted.
2. Container is wrong type. A .mov file that's actually MKV inside, or an .avi that's actually a corrupted MP4. FFmpeg picks the parser by extension (or by header sniffing) and gets the wrong one.
3. File is truncated mid-frame. FFmpeg reads up to the truncation point fine, then hits EOF in the middle of a frame and reports the next non-decodable bytes as invalid.
4. MOOV atom is missing entirely. Less common — FFmpeg usually returns "moov atom not found" specifically. But on certain malformed containers, FFmpeg falls back to the generic invalid-data message.
5. Bit-flips in the codec stream. A handful of bytes inside mdat got changed (filesystem error, bad sector). FFmpeg's decoder sees a malformed packet and bails.

How to figure out which one you've got

Run FFmpeg with verbose logging:

ffmpeg -v debug -i broken.mp4 -f null -

The verbose output usually has a more specific message before the generic invalid-data error. Look for:

• "moov atom not found" → see our MOOV page.
• "invalid NAL unit size" → codec header damage in H.264 / H.265.
• "Truncated stream" → file is cut mid-frame.
• "no audio stream" → audio metadata is broken; video may still be salvageable.
• A specific atom name like stco or stsz → MOOV is present but malformed.

If verbose mode doesn't help, try ffprobe:

ffprobe -v error -show_format -show_streams broken.mp4

If ffprobe returns useful information about streams, the file is in better shape than the FFmpeg error suggested.

What you can try yourself

Re-mux without re-encoding

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

The -err_detect ignore_err flag tells FFmpeg to skip past minor stream errors instead of bailing. Often produces a playable output even when the strict parse fails. Doesn't fix structural issues (missing MOOV, wrong container type), but rescues many "bit-flip" cases.

Try a different container

ffmpeg -i broken.mp4 -c copy out.mkv

MKV is a more forgiving container than MP4. If the codec data is intact, re-muxing into MKV often produces a file that plays everywhere.

untrunc for missing-MOOV cases

If the verbose log says "moov atom not found", follow the MOOV recovery guide.

Different player

VLC, IINA, mpv all use FFmpeg under the hood but with different decode strictness settings. Sometimes a file that fails ffmpeg -i plays fine in VLC, which means you can transcode from VLC's working playback.

How our recovery handles "invalid data" cases

The diagnostic on upload is the most important step for these files. Our pipeline runs:

• Six-pass diagnostic that doesn't rely on FFmpeg alone — runs FFmpeg, MediaInfo, and our own byte-level header probe in parallel and reconciles the results.
• Container scan independent of the declared file format. We find atoms by signature, not by extension.
• Frame-level codec detection that works even when the codec header is damaged — we re-derive parameters from the first complete frame.
• Truncation handling with safe tail-trim if the file ends mid-frame.

In practice, "invalid data found when processing input" turns into a recoverable case in the majority of files we see. Cases we can't help with: codec-data-internal corruption (bit-flips inside compressed frames) where the affected stretch is large.

What you do

1. Upload the file. Up to 50 GB.
2. ~1 minute later you get a diagnostic plus a free 5-second preview where applicable. The diagnostic tells you which underlying cause is at play.
3. If recovery is possible, you preview, pay only if it works, and download. If not, you've spent a few minutes and zero dollars.

FAQ

FFmpeg gave me this error on a file from [specific camera] — does the camera matter? Less than the error pattern. The verbose log will tell you what's wrong; from there, the recovery path is the same regardless of camera. See specific camera pages: Sony A7S III, Canon R5, GoPro Hero 12, DJI Mavic 3, Atomos Ninja.

The error appeared after I tried to convert the file with FFmpeg myself. Important question: do you still have the original file? If you do, work on it. If you only have the FFmpeg output (which may have been written incomplete on the failed conversion), the original is the recoverable file.

The error appears partway through a file that played for the first 20 seconds. Mid-file structural issue. Sometimes recoverable by trimming the bad section; sometimes by salvaging the intact head only. Diagnostic on upload tells us.

My file is technically a .mp4 but my camera writes MOV-like data inside. That's a real category. The diagnostic identifies the container by content, not by extension, so it sees through the mismatch.

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

Related

• What "MOOV atom not found" means
• MP4 file truncated — repair guide
• How our recovery engine works

Upload your file →