You point FFmpeg at a file and it refuses to start, printing Could not find codec parameters for stream 0 ... unspecified size (or similar). This means FFmpeg opened the file but could not work out enough about a stream to decode it. There are three common causes, and each has a concrete fix. This article walks through them in order, from the cheapest fix to the most thorough.
Tested with: FFmpeg 8.1
What You’ll Learn
- Why “Could not find codec parameters” is about probing, not a missing codec
- How to inspect what FFmpeg sees in the file with
ffprobe - How to make FFmpeg analyze more data with
-analyzedurationand-probesize - When the file is genuinely truncated or corrupt, and how to recover what you can
- A re-encode fallback that fixes the stream parameters in the output
The core idea: when FFmpeg opens a file, it reads a small chunk to probe each stream’s parameters (resolution, pixel format, sample rate, and so on). If that chunk doesn’t contain enough information, FFmpeg gives up with this error — even though the underlying codec is perfectly supported.
First, Inspect the File With ffprobe
Before changing options, look at what FFmpeg actually detects. ffprobe reports the streams and any parameters it managed to read, which tells you whether the problem is a single stream or the whole file.
ffprobe input.mp4
In the output, watch for streams where key fields are missing — for example a video stream with no resolution, or an audio stream with no sample rate. A stream that shows unknown or blank parameters is exactly the one FFmpeg is complaining about. If every stream looks empty, the file is more likely truncated or corrupt; if only an unusual stream is blank, you may be dealing with an exotic codec.
Cause 1: Too Little Data Was Probed
By default FFmpeg only reads a limited amount of the file to detect stream parameters. For files with a long preamble, sparse keyframes, or metadata pushed late, that default window can end before the decoder ever sees a usable frame. The fix is to tell FFmpeg to probe much more of the file using -analyzeduration and -probesize.
ffmpeg -analyzeduration 100M -probesize 100M -i input.mp4 -c copy output.mp4
-analyzeduration 100M— analyze up to 100M microseconds of the stream while probing-probesize 100M— read up to 100 MB of data while probing-c copy— once parameters are found, copy streams without re-encoding
Both options must come before -i because they affect how the input is opened. If 100M is not enough for a very large or unusual file, raise the values further. This is the cheapest fix and resolves the majority of cases where the file itself is intact.
Cause 2: A Truncated or Corrupt Stream
If raising the probe size doesn’t help, the file may simply be incomplete — a download that stopped early, a recording cut off mid-write, or bytes damaged in transit. In that case FFmpeg cannot find the parameters because the data describing them was never written or is garbled.
You often can’t fully repair such a file, but you can frequently salvage the part that is valid by re-encoding and letting FFmpeg skip the broken regions. Re-encoding rebuilds clean stream parameters in the output, so even players that choked on the original can open the result.
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac output.mp4
If the input is so badly truncated that even this fails, the data needed to decode it is genuinely missing — re-download or re-export the source if you can. For a related class of corruption errors, see Fixing “Invalid data found when processing input”.
Cause 3: An Exotic or Misdetected Codec
Sometimes the stream is fine but uses an unusual codec, or the container’s hints are wrong, so FFmpeg’s probe can’t settle on the parameters quickly. Raw streams (a bare .h264 or .aac with no container) are a classic case, since there is no header telling FFmpeg what to expect.
A robust fix is the same re-encode shown above: if ffprobe can read the streams, re-encoding forces FFmpeg to fully decode and then write a normal, well-described stream into a standard MP4, normalizing the output’s codec parameters.
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac output.mp4
-c:v libx264— re-encode video to H.264 with clean parameters-c:a aac— re-encode audio to AAC
After re-encoding, the output carries complete, standard parameters for the same error to clear on the result. For truly raw or exotic inputs, re-encoding alone may not be enough — you may also need to tell FFmpeg the input format, resolution, and framerate explicitly (for example -f rawvideo -pix_fmt yuv420p -s 1920x1080 -r 30 before -i). If the input codec itself isn’t supported by your build, that’s a different problem — see FFmpeg Codec Error.
Summary
| Cause | Symptom | Fix |
|---|---|---|
| Too little data probed | Intact file, error on open | -analyzeduration 100M -probesize 100M before -i |
| Truncated / corrupt stream | Download or recording cut off | Re-encode to salvage; re-fetch the source if needed |
| Exotic / misdetected codec | Raw stream or odd container | Re-encode to a standard MP4 |
| Diagnose first | Missing fields per stream | ffprobe input.mp4 |
FAQ
Should analyzeduration and probesize go before or after -i?
Before -i. They are input options that control how the file is opened and probed, so they must appear ahead of the input they apply to. Placing them after -i has no effect on probing.
I raised probesize to 100M and it still fails — what now?
Then the file is probably truncated or corrupt rather than just under-probed. Try the re-encode fallback ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac output.mp4 to salvage the valid portion. If even that fails, the source data needed to decode the stream is genuinely missing.
Does this error mean FFmpeg lacks the codec?
No. “Could not find codec parameters” is about probing the stream’s settings, not about a missing decoder. If the codec itself were unsupported you would instead see a different message about an unknown or unsupported codec. Use ffprobe to confirm which streams are unreadable.
Why does ffprobe show some streams but not their parameters?
That is the same probing problem in diagnostic form: FFmpeg detected the stream exists but couldn’t read enough to fill in resolution, sample rate, and so on. Increasing -analyzeduration and -probesize, or re-encoding, usually populates those parameters in the output. For raw or exotic inputs you may also have to specify the input format, resolution, and framerate explicitly.
Related Articles
- Fixing Common FFmpeg Errors
- FFmpeg Codec Error: Causes and Fixes
- Fixing “Invalid data found when processing input”
- How to Convert Video to MP4
Tested with FFmpeg 8.1 — verified with our command-check script
Primary sources: ffmpeg.org/ffmpeg.html / ffmpeg.org/ffmpeg-codecs.html