You run FFmpeg on a file and it prints Could not find codec parameters for stream 0 ... unspecified size or a similar line. FFmpeg opened the file but could not learn enough about a stream to decode it. The line is a warning, so FFmpeg carries on, but the job may then fail with another error or leave that stream out of the output. There are three common causes. The fixes below go from the cheapest to the most thorough.
When FFmpeg opens a file, it reads a small chunk to probe (detect) each stream’s parameters: resolution, pixel format, sample rate and so on. If that chunk does not contain enough information, FFmpeg prints this message, even when it fully supports the codec.
First, Inspect the File With ffprobe
Before changing options, check what FFmpeg detects. ffprobe lists the streams and the parameters it could read, so you can see whether one stream or the whole file is the problem.
ffprobe input.mp4In the output, look for streams with missing fields, such as a video stream with no resolution or an audio stream with no sample rate. A stream that shows none in place of a value, or has no size or sample rate, is the one the message is about. If every stream looks empty, the file is more likely truncated or corrupt. If only an unusual stream is blank, it may use an exotic codec.
Cause 1: Too Little Data Was Probed
By default FFmpeg reads only part of the file to detect stream parameters. In files with a long preamble, few keyframes or metadata placed late, that window can end before the decoder sees a usable frame. Tell FFmpeg to probe much more of the file with -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
Put both options before -i, because they control 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, so try it first when the file itself is intact.
Cause 2: A Truncated or Corrupt Stream
If a larger probe size does not help, the file may be incomplete: a download that stopped early, a recording cut off while it was being written, or bytes damaged in transfer. FFmpeg cannot find the parameters because the data that describes them was never written or is garbled.
You often cannot fully repair such a file. You can frequently save the valid part, though, by re-encoding and letting FFmpeg skip the broken regions. The re-encoded output gets clean stream parameters, so players that failed on the original can open it.
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac output.mp4If even this fails, the data needed to decode the stream is missing. Download or export the source again if you can. For a related corruption error, see Fixing “Invalid data found when processing input”.
Cause 3: An Exotic or Misdetected Codec
Sometimes the stream is fine, but it uses an unusual codec or the container gives wrong hints, so the probe cannot settle on the parameters quickly. Raw streams (a bare .h264 or .aac file with no container) are a typical case. Without a container, FFmpeg has to read the size or sample rate from headers inside the stream (SPS/PPS in H.264, ADTS headers in AAC). If those headers are missing, it cannot settle the parameters.
The fix is the same re-encode as above. If ffprobe can read the streams, re-encoding makes FFmpeg decode them fully and write normal, fully described streams into a standard MP4.
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
The output then carries complete, standard parameters, so the error does not come back when you open it. For raw or exotic inputs, re-encoding may not be enough. You may also need to give FFmpeg the input format, resolution and frame rate yourself (for example -f rawvideo -pix_fmt yuv420p -s 1920x1080 -r 30 before -i). If your build does not support the input codec at all, that is 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 go ahead of the input they apply to. After -i they have no effect on probing.
I raised probesize to 100M and it still fails — what now?
Then the file is probably truncated or corrupt, not just under-probed. Re-encode with ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac output.mp4 to save the valid part. If that also fails, the data needed to decode the stream is missing.
Does this error mean FFmpeg lacks the codec?
Usually not. “Could not find codec parameters” is about probing the stream’s settings, and it also appears for codecs FFmpeg supports. But if the line ends with unknown codec and shows none where the codec name should be, FFmpeg does not recognize the codec: see FFmpeg Codec Error. Use ffprobe to see which streams cannot be read.
Why does ffprobe show some streams but not their parameters?
It is the same probing problem. FFmpeg found the stream but could not read enough to fill in the resolution, sample rate and so on. Raising -analyzeduration and -probesize, or re-encoding, usually fills in those parameters in the output. For raw or exotic inputs you may also have to set the input format, resolution and frame rate yourself.