FFmpeg: Fix "Invalid data found when processing input"

You point FFmpeg at a file and it stops immediately with Invalid data found when processing input. Nothing gets converted. This error means FFmpeg opened the file but could not make sense of its contents — the bytes don’t match what the container claims to be. The good news is that the causes form a short list, and you can work through them in order: first confirm what the file actually is, then try the least destructive repair, and only re-encode if nothing else works.

Tested with: FFmpeg 8.1 (verified against real FFmpeg)

What You’ll Learn

The four typical causes of Invalid data found when processing input
How to check what the file really is with ffprobe before touching it
How to re-mux with error tolerance to salvage a slightly damaged file
How to repair missing timestamps in a partial file with +genpts
When to give up on copying and re-encode as a last resort

The error points at the input, so that’s where the investigation starts. In most cases the file is either truncated, mislabeled, or only partially downloaded — all of which are recoverable to some degree once you know which one you’re dealing with.

Common Causes

Invalid data found when processing input is FFmpeg’s way of saying “I read the header (or part of it) and it doesn’t add up.” The usual suspects are:

Truncated or partial download — the file is incomplete because a download or copy was interrupted. The end of the file is missing, so the moov atom (for MP4) or the index never arrived.
Not actually a media file — e.g. an HTML error page, a partial download, or some other non-media data saved as video.mp4. FFmpeg reads the bytes, not the name, so a valid file with the wrong extension (a real .webm named .mp4) still opens fine; you only get this error when the bytes aren’t a usable media container at all (or are an unsupported/corrupt one). A wrong extension on a valid file is a media-player problem, not an FFmpeg one.
Actual corruption — bytes were flipped or dropped on a bad disk, a flaky transfer, or a failed recording.
Unsupported or exotic container — a rare format your FFmpeg build wasn’t compiled to demux.

The fix path is the same regardless of cause: identify, then attempt the cheapest repair first.

Step 1: Check What the File Really Is

Before any repair, run ffprobe. It reports the actual container and streams FFmpeg detects, which immediately tells you whether the file is the format you think it is.

ffprobe input.mp4

Read the first lines of the output carefully:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
  Duration: 00:01:23.45, start: 0.000000, bitrate: 1536 kb/s
  Stream #0:0: Video: h264 (High), yuv420p, 1280x720, 30 fps
  Stream #0:1: Audio: aac, 44100 Hz, stereo

If ffprobe itself reports Invalid data found, the bytes are damaged, incomplete, unsupported, or not media data at all — that is the real problem. If instead ffprobe detects a valid format that merely differs from the extension (for example Input #0, matroska,webm on a file named .mp4), FFmpeg can already read it — a true .webm saved as .mp4 still works. Rename it to the format ffprobe reports (e.g. input.webm) only for clarity and player compatibility, not for FFmpeg’s sake.

If ffprobe reports a sane duration and streams but FFmpeg still errors mid-conversion, the file is likely slightly damaged or truncated — move to Step 2.

Step 2: Re-mux with Error Tolerance

If the streams are essentially valid but there’s some garbage in the file, you can often copy the good packets straight into a fresh container. -c copy avoids re-encoding (fast and lossless), and -err_detect ignore_err tells FFmpeg to push past minor errors instead of aborting.

ffmpeg -err_detect ignore_err -i input.mp4 -c copy output.mp4

-err_detect ignore_err — keep going when a recoverable error is hit
-c copy — copy all streams without re-encoding
output to a fresh file — a clean container with a rebuilt index

This rewrites the container from the salvageable packets. If the only damage was a broken index or some trailing junk, the new output.mp4 will often play perfectly. Because it’s a copy, it costs nothing in quality and takes only seconds.

Step 3: Rebuild Timestamps for Partial Files

A file whose download was cut off frequently has missing or broken presentation timestamps (PTS), which can surface as invalid-data or “non-monotonous DTS” errors during processing. The -fflags +genpts flag tells FFmpeg to generate presentation timestamps where they’re missing.

ffmpeg -fflags +genpts -i input.mp4 -c copy output.mp4

-fflags +genpts — generate missing presentation timestamps
-c copy — still no re-encoding

This is the right move for partial recordings and interrupted downloads where the video data is present but the timing metadata is incomplete. You can combine it with the error tolerance from Step 2 if a single flag isn’t enough: ffmpeg -err_detect ignore_err -fflags +genpts -i input.mp4 -c copy output.mp4.

Step 4: Re-encode as a Last Resort

When copying fails — the packets themselves are damaged, not just the container — your last option is to fully decode and re-encode. This forces FFmpeg to read every frame it can and write out a brand-new, clean file, dropping whatever it cannot decode.

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac output.mp4

-c:v libx264 -crf 23 — re-encode the video at a sensible quality
-c:a aac — re-encode the audio to AAC
the decode step reconstructs as much as possible and discards the unrecoverable

Re-encoding is slower and slightly lossy, but it’s the most forgiving option: it can rescue files that no copy operation will touch. Treat it as the final step, after ffprobe, error-tolerant re-mux, and timestamp repair have all come up short.

Summary: Fixes in Order

Step	Command	Cost	Use when
1. Identify	`ffprobe input.mp4`	None	Always first — find the real format
2. Re-mux	`ffmpeg -err_detect ignore_err -i input.mp4 -c copy output.mp4`	Seconds, lossless	Streams valid, container junk
3. Fix PTS	`ffmpeg -fflags +genpts -i input.mp4 -c copy output.mp4`	Seconds, lossless	Partial / interrupted file
4. Re-encode	`ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac output.mp4`	Slow, slightly lossy	Nothing else worked

Always go top to bottom. The early steps cost nothing and frequently solve it; re-encoding is the heavy hammer you reach for only when copying refuses.

FAQ

ffprobe says the format doesn’t match the extension — what do I do?

FFmpeg reads the real bytes, not the extension, so it can already open the file with the right demuxer regardless of the name — the wrong extension mainly trips up media players and people. Renaming it to the format ffprobe reports (a .webm saved as .mp4 becomes input.webm) is for clarity and player compatibility, not to make FFmpeg work. If ffprobe itself reports invalid data, the file is genuinely damaged, not just mislabeled.

My download was interrupted — can FFmpeg still save it?

Often yes. A partial file usually has valid video for the portion that arrived, just with missing end-of-file metadata or timestamps. Try the re-mux in Step 2, then add -fflags +genpts from Step 3. You’ll get a shorter clip covering what was downloaded, which is usually better than nothing.

Re-muxing produced a file but it cuts off early. Why?

Because that’s how far the intact data went. Error-tolerant copying salvages everything up to the point of damage and stops cleanly there. If you need more of it, the data past that point is likely unrecoverable; re-encoding (Step 4) sometimes squeezes out a few extra frames but cannot invent missing bytes.

Is this the same as a “moov atom not found” error?

They’re closely related but not identical. “moov atom not found” is a more specific MP4 case where the index (the moov atom) is missing — typically from a truncated download. Be aware of an important caveat: if the moov atom is truly missing, FFmpeg usually cannot demux any packets at all, so -err_detect ignore_err, -fflags +genpts, and re-encoding generally cannot recover such a file — those only help when FFmpeg can still demux usable streams. A genuinely missing moov atom typically needs the original/reference recording or a specialized repair tool (such as untrunc). See the dedicated moov atom guide for details.

Could it just be an outdated FFmpeg build?

Rarely, but it’s worth ruling out for unusual containers. If ffprobe shows a format your build doesn’t list as supported, updating to the latest FFmpeg may add the demuxer. For mainstream formats like MP4, MKV, and WebM, an outdated build is almost never the cause — suspect a damaged or mislabeled file first.

Tested with FFmpeg 8.1 — verified with our command-check script
Primary sources: ffmpeg.org/ffmpeg.html / ffmpeg.org/ffmpeg-filters.html#scale / trac.ffmpeg.org/wiki/Scaling