You run FFmpeg on a file and it stops at once with Invalid data found when processing input. Nothing is converted. FFmpeg opened the file but could not make sense of its contents: the bytes do not match what the container claims to be. The causes are few, and you can work through them in order. First confirm what the file really is, then try the least destructive repair, and re-encode only if nothing else works.
The error is about the input, so start there. In most cases the file is incomplete, damaged or not a media file at all. Find out which one you have first; only some of these can be recovered.
Common Causes
The message means FFmpeg read the header (or part of it) and it did not make sense. The usual causes are:
- Truncated or partial download — a download or copy was interrupted, so the end of the file is missing. The moov atom (in an MP4) or the index never arrived.
- Not actually a media file — for example an HTML error page, a partial download or other non-media data saved as
video.mp4. FFmpeg goes by the bytes, not the name, so a valid file with the wrong extension (a real.webmnamed.mp4) still opens. You get this error only when the bytes are not a usable media container at all, or are an unsupported or corrupt one. A wrong extension on a valid file is a problem for media players, not for FFmpeg. - Actual corruption — bytes were flipped or lost on a bad disk, in a faulty transfer or in a failed recording.
- Unsupported or exotic container — a rare format that your FFmpeg build was not compiled to demux (read).
Whatever the cause, the order is the same: identify the file, then try the cheapest repair first.
Step 1: Check What the File Really Is
Before any repair, run ffprobe. It shows the container and streams FFmpeg detects, so you see at once whether the file is the format you think it is.
ffprobe input.mp4Check the first lines of the output:
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, stereoIf ffprobe also reports Invalid data found, the bytes are damaged, incomplete, unsupported or not media data at all. That is the real problem. If ffprobe detects a valid format that only differs from the extension (for example Input #0, matroska,webm on a file named .mp4), FFmpeg can already read it. Renaming it to the format ffprobe reports (for example input.webm) helps people and media players, not FFmpeg.
If ffprobe shows a sensible duration and streams but FFmpeg still fails partway through a conversion, the file is probably slightly damaged or truncated. Go to Step 2.
Step 2: Re-mux into a New File
If the streams are mostly valid but the file contains some garbage, you can often copy the packets into a new container. -c copy skips re-encoding (fast and lossless). -err_detect ignore_err is not needed here: it only affects decoding, and a copy does not decode.
ffmpeg -i input.mp4 -c copy output.mp4-c copy— copy the output streams without re-encoding- output to a fresh file — a clean container with a rebuilt index
This writes a new container from the packets that can be saved. If the only damage was a broken index or some junk at the end, the new output.mp4 often plays normally. Because it is a copy, it loses no quality and takes only seconds.
Step 3: Generate Missing Timestamps
Some files, such as AVI files with B-frames, have packets with a decoding timestamp (DTS) but no presentation timestamp (PTS). Copying them to MP4 then prints pts has no value. -fflags +genpts tells FFmpeg to generate the missing PTS from the DTS.
ffmpeg -fflags +genpts -i input.mp4 -c copy output.mp4-fflags +genpts— generate missing presentation timestamps-c copy— still no re-encoding
It does not repair a cut-off file. An MP4 keeps its timing in the moov atom, which +genpts cannot rebuild. A Non-monotonic DTS message is a warning: FFmpeg adjusts the timestamp and carries on, and +genpts does not change that.
Step 4: Re-encode as a Last Resort
When copying fails because the packets themselves are damaged (not only the container), the last option is to decode and re-encode everything. FFmpeg then reads every frame it can, drops what it cannot decode and writes a new, clean file.
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 is the most tolerant option and can rescue files that copying cannot. Use it last, after ffprobe, the re-mux and the timestamp repair have not worked.
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 -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 | Packets without PTS (pts has no value) |
| 4. Re-encode | ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac output.mp4 |
Slow, slightly lossy | Nothing else worked |
Work from top to bottom. The early steps cost nothing and often solve the problem. Re-encode only when copying fails.
FAQ
ffprobe says the format doesn’t match the extension — what do I do?
FFmpeg reads the bytes, not the extension, so it already opens the file with the right demuxer whatever the name. The wrong extension mainly confuses media players and people. Renaming the file to the format ffprobe reports (a .webm saved as .mp4 becomes input.webm) is for clarity and player compatibility; FFmpeg does not need it. If ffprobe itself reports invalid data, the file is damaged, not just mislabeled.
My download was interrupted — can FFmpeg still save it?
It depends on the format. With TS, MKV or an MP4 whose moov is at the start (faststart), you can often recover the part that arrived. Try the re-mux in Step 2. You get a shorter clip that covers what was downloaded. A regular MP4 keeps its moov at the end. If the end is missing, that is the “moov atom not found” case below, and FFmpeg alone can almost never recover it.
Re-muxing produced a file but it cuts off early. Why?
That is where the intact data ends. Copying saves everything up to the damage and stops there. The data after that point is probably lost. Re-encoding (Step 4) sometimes recovers a few more frames, but it cannot recreate missing bytes.
Is this the same as a “moov atom not found” error?
They are related but not the same. “moov atom not found” is a specific MP4 case: the index (the moov atom) is missing, usually because a download was cut short. If the moov atom is really missing, FFmpeg usually cannot demux any packets at all. -err_detect ignore_err, -fflags +genpts and re-encoding then generally cannot recover the file; they only help when FFmpeg can still demux usable streams. A missing moov atom usually needs the original or a reference recording, or a specialized repair tool such as untrunc. See the moov atom guide for details.
Could it just be an outdated FFmpeg build?
Rarely, but check it for unusual containers. If your build has no demuxer for the format, ffprobe cannot name it and reports the same Invalid data found error. Updating to the latest FFmpeg may add the demuxer. For common formats such as MP4, MKV and WebM, an outdated build is almost never the cause. Suspect a damaged file, or one that is not media at all, first.