How do I fix the FFmpeg YouTube stream error “Invalid data found when processing input”? Start by finding the exact filename FFmpeg rejected, then probe that input and read the earlier log lines to locate the first failure. The message signals that FFmpeg encountered data it could not process; it does not identify one cause or guarantee that downloading again will solve it.
A partial download, a response that is not media, corrupt or unsupported data, and a later merge or post-processing problem can look similar at the end of a log. Work through the stages in order so you do not repeatedly rename or re-encode a file before establishing what it contains.
What the error does and does not tell you
The FFmpeg Project assigns the text “Invalid data found when processing input” to its AVERROR_INVALIDDATA error code. That is a description of the kind of failure FFmpeg reported, not a diagnosis of why the bytes were rejected. The message alone cannot tell you whether the problem began during extraction, transfer, parsing, or a later operation. See the FFmpeg error-code documentation.
The surrounding command matters. FFmpeg may be opening a local file produced by yt-dlp, reading a remote URL, or combining separately downloaded audio and video. The same final error can appear after different preceding events, so the useful question is not simply “What does invalid data mean?” but “Which input was FFmpeg handling, and what happened immediately before it failed?”
This is why advice such as “just re-encode it” is premature. Re-encoding requires FFmpeg to read the source first. If the input is an HTML error page, an incomplete transfer, or bytes that do not form a readable media stream, changing output settings does not repair the source. Conversely, a file that ffprobe can read may be failing during a specific merge or remux operation, which calls for a different investigation.
Keep the distinction between the symptom and the diagnosis in view throughout the checks below. Do not assume a particular cause from the wording, and do not treat a successful probe as proof that every later operation will work.
Find the exact input named in the error
Read upward from the last FFmpeg error. Look for a line that names an input, often next to wording such as Error opening input, Invalid data found when processing input, or a command-line -i option. Copy the filename exactly, including its directory, punctuation and extension. A common mistake is to probe the intended video while FFmpeg actually rejected a temporary audio file or a differently named download.
Then find the command that launched FFmpeg and identify the stage it belongs to. Was yt-dlp still extracting or downloading? Had it declared the download complete and started a merge? Was another script trimming, remuxing or converting a finished file? If the log includes separate audio and video paths, check which one the failed command lists as its input before drawing conclusions about the other.
Preserve a small evidence set before changing anything: the exact command, the failed filename and extension, its file size, the yt-dlp completion message if present, and the first warning before the final error. Note whether the job used --download-sections, handled a live or post-live video, or selected a particular format. These details narrow the next check; they are not proof of a cause by themselves.
A filename can be misleading. An extension such as .mp4 does not demonstrate that the contents are MP4 media, and a different extension does not prove that valid media is unreadable. Do not rename the file simply to make it look right. Use ffprobe to inspect what FFmpeg can actually detect.
For a 24/7 channel workflow, this same habit of locating the failed stage is useful beyond downloads: a stream can fail during preparation, upload, or the live session itself. If your concern is the broadcast connection rather than a downloaded input file, use the separate guide on checking whether your upload speed is enough for YouTube live streaming rather than treating every FFmpeg error as a network diagnosis.
Probe the named file with ffprobe
Run ffprobe against the exact local path FFmpeg rejected:
ffprobe -hide_banner -v error -show_format -show_streams "input-file"
Replace input-file with the full filename, including its extension. Keep the quotation marks if the path contains spaces. This asks ffprobe to report detected container information and streams while suppressing routine banner output. Save what it prints, including any errors; an empty result and a clear probe failure are evidence too.
If ffprobe reports a format and one or more streams, record what it detected. You may see video and audio stream entries, or only one type of stream. Compare that result with the next operation in your command: for example, a merge needs inputs and stream types appropriate to that merge. A recognised format does not establish that the file is complete, that every packet is readable, or that a particular stream-copy operation will succeed.
If ffprobe cannot detect a usable container or streams, do not move straight to a re-encode. First establish whether the file is actually media and whether it is complete. If it is a partial transfer or a non-media response, the sensible next action is to correct the acquisition problem and obtain a valid input. If it is a known but unsupported or damaged form, identify that before choosing a conversion or a different tool version.
You can compare the reported format with the filename, but do not force them to match by renaming alone. A container can sometimes be detected despite a misleading extension. The probe is useful because it reports what the data looks like to FFmpeg; the extension is only a label supplied by the filesystem.
Check whether the input is media at all
A failed download does not always leave an obviously empty file. A server response, access-denied page, or other text may be saved using a video extension. If ffprobe reports no media streams, inspect the file’s size and, where appropriate, a small text preview or file-type identification. Avoid posting the full contents of a file or signed URL publicly; the point is to establish whether you have media bytes, not to expose credentials or session data.
Check the downloader’s log for completion. Did yt-dlp announce that it finished downloading, or did the process stop, report a network error, or leave a temporary filename behind? Compare the saved file’s size with any earlier copy you know was complete. A small or zero-byte file is a clue, not a universal threshold: there is no single size that proves a download is valid for every video.
If FFmpeg was given a remote URL directly, verify that the command is passing a media stream URL that remains accessible, rather than a watch page or an expired address. A URL that worked earlier may not remain valid. Do not paste signed URLs, cookies, or authorisation headers into a public bug report.
Only once you have a media input should you investigate codecs, container support, or conversion. If the file is actually a response page or a truncated transfer, repeated remux attempts cannot create the missing media. If you are building a local playback workflow for a continuous channel, the Raspberry Pi playlist guide also explains why the source files and the streaming process need to be treated as separate parts of the setup.
Investigate partial, corrupt or unsupported data
When ffprobe recognises a format but the next operation fails, inspect the details rather than assuming the file is healthy. Check whether the download completed, whether the failure occurs at a consistent point, and whether the log identifies one stream or one input among several. A file may contain readable metadata yet have damaged or missing media packets later in the data. Repeating a merge command on the same unchanged inputs is unlikely to add information.
If you have a known-good copy of the same source, compare probe output and file sizes. If only one copy fails, reacquiring that input is a reasonable test. If the same file parses but fails only during one specific operation, preserve that distinction and investigate the operation itself. Do not force a format selection or transcode as a general remedy; those steps are only useful when they address the actual incompatibility and can read the source.
FFmpeg version advice should also be tied to evidence. The yt-dlp maintainers’ known-issues page describes particular FFmpeg regressions, not a general rule that the latest build fixes every invalid-data error. For a live, post-live or DASH video with duplicate ftyp data, that page recommends FFmpeg 6.1.1 or later, or a master build at revision N-112916 or later. For a separate HDR VP9 in MP4 case, it recommends FFmpeg 7.0.1 or latest master. These are targeted recommendations for the described cases; match the media and failure evidence before applying them.
A useful comparison is to sort the evidence along three axes: where the failure occurred, what kind of input you have, and which tool versions are involved. This keeps a specific workaround from turning into folklore for unrelated files.
| Evidence in your case | Next check | Avoid assuming |
|---|---|---|
| Extractor warning before any completed file | yt-dlp version and extraction log | That a local media file is corrupt |
| No streams detected by ffprobe | File contents, completion status and acquisition | That an extension change will make it media |
| Streams detected, failure during merge | Exact inputs, merge command and stream details | That the download itself is necessarily unusable |
Live/post-live/DASH input with duplicate ftyp evidence |
Match the FFmpeg version to the documented issue | That the version guidance applies to ordinary files |
| HDR VP9 in MP4 with matching issue evidence | Check the targeted FFmpeg recommendation | That an update is a universal fix |
Retry a failed download with current yt-dlp
If the log points to extraction or an incomplete acquisition, update yt-dlp before trying the job again. The project documents yt-dlp -U for its release binary; if you installed it with pip, use the same installation method you originally used. If a problem remains on stable, yt-dlp’s project guidance says to try nightly before filing a bug report; its documented binary command is yt-dlp --update-to nightly. Package-manager installations should be updated through the package manager rather than mixing installation methods.
A newer downloader is relevant when the earlier log shows an extractor, signature, or download problem. It is not a substitute for checking a local file that has already been verified as media, and it cannot guarantee success against every source or processing failure. Run the same acquisition again only after noting the first attempt’s command and outcome, so you can tell whether the input changed and whether the first failure recurs.
The yt-dlp project also lists yt-dlp-ejs as required for full YouTube support. If the log specifically indicates extractor or signature trouble, check that the relevant extraction components are installed and current using the project’s own installation and update guidance. Do not infer that a missing component is the issue unless the log or installation details point that way.
After retrying, probe the newly saved file, not the earlier failed copy. Confirm that the downloader finished and that ffprobe detects the expected format and streams. If the new file still fails, keep both the new verbose log and the probe output; the point is to identify whether the failure moved from extraction to input parsing or remained at the same stage.
Separate input failure from post-processing
A frequent source of confusion is that yt-dlp can finish obtaining separate audio and video inputs, then fail when FFmpeg merges or remuxes them. Read the exact FFmpeg command in the log and identify every -i input. Probe each path individually. One input may be readable while another is incomplete, or the failure may occur only when a particular combination is processed.
Look at the first relevant warning, not just the last line. A documented section-download issue, for example, includes an nsig extraction failed warning before later FFmpeg input errors. A separate report shows completed fragments followed by an audio file being rejected during a stream-copy merge. These examples illustrate why the final message alone cannot select a root cause; they are not proof that your job has the same problem. The issue report involving section downloads and the report involving a later merge are useful for understanding how different sequences can end with similar errors.
If your command uses --download-sections, record that fact and check whether the warning appeared during extraction or when FFmpeg later opened an input. If it does not use section trimming, do not add it as a speculative fix. Likewise, do not switch to a different format or force re-encoding simply because a merge failed. First establish which input is rejected and whether the operation is appropriate for the detected streams.
When sharing a report, include the exact command, complete verbose output, yt-dlp and FFmpeg/ffprobe versions, selected format or formats, the failed filename, whether the source was live/post-live or HDR VP9, and whether section trimming was used. Redact cookies, authorisation headers, signed stream URLs and other private data. A report containing only the final error line usually omits the evidence needed to distinguish extraction from parsing or post-processing.
If your actual need is not to download and merge a source but to keep a prepared video running as a YouTube live channel, consider whether maintaining a local FFmpeg job is the right workflow. StreamNeo removes the need to keep your own computer running a file-based broadcast, which addresses that specific overnight-machine burden; it does not diagnose or repair a broken input file.
Make the next attempt evidence-led
Before changing versions or commands, write down the first failing stage and the result of probing the named input. Then change one relevant thing at a time. If you update yt-dlp, retain the same source and note the new outcome. If you test a targeted FFmpeg version recommendation, record the version and confirm that your media matches the documented case. Changing downloader, format, filename and FFmpeg build together makes the result harder to interpret.
A practical decision sequence is: an extractor warning points you towards yt-dlp and its current guidance; a file with no detected streams points you towards completion and whether it is media; readable streams followed by a merge failure point you towards the command and each merge input; a matching, documented media/version regression makes the targeted FFmpeg advice relevant. If no branch fits, do not invent one. Gather the complete log and versions, then ask for help with evidence rather than applying unrelated fixes.
For a live-channel operator, keep the prepared source file and the live broadcasting arrangement as separate concerns. If the video file is valid but your continuous broadcast drops frames, that is a different fault from this input-data message; the guide to fixing OBS dropped frames during a 24/7 church sermon stream covers a distinct live-session troubleshooting path. Clear distinctions save time when one job has several tools and stages.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does this error mean my YouTube download is corrupt?
Not necessarily. It means FFmpeg reported invalid data while processing an input, but the message alone does not establish whether the input is corrupt, incomplete, not actually media, or involved in a later processing failure. Probe the exact filename in the error and read the preceding log lines.
Should I download the video again?
Retrying is sensible when the first log or file checks point to an incomplete download, failed extraction, or non-media response. It is not a guaranteed fix for every case, and it will not address a merge or version-specific processing issue just because the same final error appears. Probe the new file and compare the stage where the failure occurs.
What should I include when asking for help?
Include the exact command, complete verbose log, tool versions, selected formats, failed input filename and ffprobe output. Note whether the source is live/post-live or HDR VP9 and whether section trimming is enabled, if relevant. Redact cookies, authorisation data and signed URLs before sharing.
Can I fix it by changing the file extension?
An extension is a label, not evidence of the data inside the file. Use ffprobe to see what format and streams it detects before renaming anything. If it detects no usable media, a different extension will not turn a response page or partial transfer into a valid video.