If your FFmpeg YouTube Live loop stops with Invalid data found when processing input, the message tells you that FFmpeg could not process data at an input stage; it does not identify one particular fault. Start by checking the exact input named in the full command and log, then probe that same file or URL with ffprobe before changing the streaming output settings.
The cause might be an incomplete or damaged file, a URL returning something other than media, an unreadable container, or a problem with a concat list. Without your command, input and complete log, nobody can identify which applies. Work through the checks below in order and make one change at a time.
What “Invalid data found” tells you
FFmpeg’s error reference labels AVERROR_INVALIDDATA as “Invalid data found when processing input”. That is a description of the failure, not a diagnosis of its origin. The error can occur in different workflows and at different stages, so the words alone do not prove that a video is corrupt or that a YouTube setting is wrong. See the FFmpeg error reference for the official label.
A loop command may read one file directly, fetch media from a URL, or pass a text list to the concat demuxer. Each arrangement has different things to check. A .mp4 suffix, for example, does not confirm that the bytes at that path are an MP4 file. Similarly, a stream that appeared to start before failing is not necessarily failing for the same reason as a command that stops immediately while opening its input.
It helps to separate three questions: which input was being read, what kind of data was actually received, and when the error appeared. Answering those is more useful than swapping encoder flags at random. If the input is readable locally but YouTube later shows the stream as offline, that is a different diagnostic branch; the checks for an FFmpeg stream that shows offline after starting address that symptom.
Capture the complete command and error context
Save the exact command you ran and the entire console output, starting before FFmpeg opens the inputs and ending at the failure. Include every -i argument, any -f concat option, the loop options, and the output URL with its stream key removed. Do not post the key publicly. Keep the input paths, filenames and relevant options intact, or replace private names consistently so it remains clear which path is which.
Look for the last messages that identify an input, format or stream before the error. Note whether FFmpeg names the local media file, a URL, or the concat list itself. Also note whether it fails immediately during input opening or only after reading packets for a while. An error while parsing input data is not the same evidence as a message that the output connection or YouTube ingest has rejected a stream.
If the log is long, do not trim away the opening lines or the first error. Later messages may merely repeat the consequence of an earlier failure. Keep a copy of the original log before trying a repair; otherwise a changed command may obscure what first happened. If you ask someone to help, the command, input type and complete log are the useful evidence. The title of the error is not enough to choose a specific fix.
Test the exact input with ffprobe
Run ffprobe against the same local file or URL that the failing FFmpeg command reads. For a local file, a basic check is:
ffprobe -hide_banner -i input.mp4
Replace input.mp4 with the real path. For a URL, use the exact URL supplied to FFmpeg, taking care not to expose tokens or credentials when sharing the result. The purpose here is inspection, not a guaranteed repair: note whether ffprobe recognises a container, reports a duration, and identifies audio or video streams. The FFmpeg Cookbook’s invalid-data troubleshooting guide also puts probing the input before attempts to repair it.
A successful probe is evidence that FFmpeg can read at least the inspected input structure. It does not prove that every packet is intact, that a long loop will run indefinitely, or that YouTube will accept the output. If the probe reports streams and a format but your command still fails, compare the input path and options in the working probe with those in the failing command. Make sure you have not tested a different copy, a different URL or a downloaded file in place of a live source.
If the probe fails, preserve its output and compare it with the original FFmpeg log. The wording and the point of failure may help narrow the branch, but avoid treating one line as proof of corruption. A path typo, an inaccessible file, an unexpected URL response, a truncated download or lack of support for a particular format are possibilities to investigate, not facts established by this error alone.
Check for media or an unexpected response
For a local file, confirm that the path resolves to the file you intended, that it is readable by the account running FFmpeg, and that a copy or download has finished. If the file came from a download, check it again after the transfer completes. An interrupted download can leave a file with a familiar extension that does not contain a complete media stream.
For a URL, confirm that it returns media to the FFmpeg process rather than a web page or error message. A browser may display a login page, access-denied notice or expired-link message where FFmpeg expects media bytes. Redirects, authentication and expiring URLs can make a link behave differently from a static file. Do not infer the response type from the URL’s suffix alone; inspect the exact endpoint and the probe output.
When you can save a response for inspection, use a copy and avoid overwriting the original source. If the saved content begins as readable HTML or a service error, the immediate problem is the response, not a video codec setting. Resolve the path, access or link issue first, then probe the media that the command will actually use. If the URL is a playlist or another source that references media, inspect what it points to as well.
Keep the output side unchanged during this check. Your stream key controls where FFmpeg sends the output; it does not turn an HTML response or a missing local file into media. If the input checks pass and you then need to verify the output command separately, the guide to adding a YouTube stream key to FFmpeg on Ubuntu covers that distinct part of the workflow.
Inspect the container and codec support
When ffprobe recognises the file, record the detected container and the audio and video codecs. A filename ending in .mp4 may contain different data from what the suffix suggests; conversely, a different extension does not automatically mean FFmpeg cannot read it. The detected format and streams are better evidence than the name. Check whether the file’s actual structure matches what your command assumes.
A container is the wrapper that organises media streams, while codecs describe how the audio or video is encoded. FFmpeg must be able to demux the container and decode or copy the streams as required by the command. If a file is valid but uses a format your installed FFmpeg build cannot read, changing YouTube’s ingest settings will not add that support. First establish which demuxer or decoder is missing from the evidence; do not assume that is the issue simply because the probe failed.
If a file probes successfully but playback or processing fails later, the failure may be localised to a portion of the media rather than its initial header. Try reading or playing the file independently, and if practical test a copy or a short excerpt around the point where processing stops. Keep the original unchanged. The particular repair depends on whether the evidence points to container organisation, timestamps or damaged packets.
A stream-copy remux can be worth testing on a copy when packets appear mostly readable but the container needs to be rewritten. For example, the cookbook guide shows ffmpeg -i input.mp4 -c copy output.mp4 as a remux example. It does not re-encode the audio or video, and it cannot restore missing or damaged media. Use it only when the diagnosis fits, then probe the new file before substituting it into a live loop.
Timestamp generation is likewise conditional. The guide discusses -fflags +genpts for missing presentation timestamps; it is not a general response to Invalid data found. Re-encoding takes more processing and may alter quality, so consider it only when the packets themselves need to be decoded and rebuilt. Any such test should be done on a separate file, not as an unexplained change to the production command.
Review concat-list syntax and file paths
If your command uses -f concat -i list.txt, FFmpeg is first asked to read a concat script. Check that the file passed after -i is really the list you mean to use, not a media file or an empty, stale list. Open it as text and confirm the expected file entries are present. Each referenced path must exist and be readable from the working directory and account used by the process.
Relative paths are resolved in relation to the list file’s location, which can differ from the directory where you manually test a command. If a path works in an interactive shell but not in a scheduled job or a different working directory, test with the same execution context or make the path arrangement explicit. Watch for spaces, quoting and accidental characters in filenames; a list that looks plausible can still name a file that FFmpeg cannot open.
FFmpeg documents the concat demuxer and its safe option in its formats documentation. With safe-path checks enabled by default, some paths are rejected as unsafe. That is a path-acceptance rule, not proof that the media is invalid. Do not add -safe 0 as a reflex: it changes which paths the demuxer accepts and does not repair unreadable files, a malformed list or non-media content. If the option is appropriate for your controlled list, understand the consequence and verify each referenced path first.
For a list-based loop, test each entry independently with ffprobe before testing the list. This tells you whether one particular file is unreadable or the list arrangement is the failing part. If individual inputs probe successfully but the concat input does not, inspect the list syntax, ordering, paths and the exact concat options. For a working example of a playlist arrangement, see how to build a 24/7 Indian classical music stream with FFmpeg concat; treat it as a reference for the arrangement, not a substitute for checking your own files.
Retry with the smallest valid input
Once the exact media probes successfully, reduce the test to one known-good input and keep unrelated output settings fixed. If your normal workflow uses a list, test a single list entry before restoring the full rotation. If you use a URL, verify the same URL rather than a downloaded substitute. A short local read or playback test can establish that the media is accessible without leaving a live broadcast to fail repeatedly.
Then restore the loop mechanism, and only after that reintroduce other inputs or options one at a time. If the simple input works but the list fails, return to the list. If local processing works but the live output fails, preserve that new evidence and investigate the output connection separately. This staged approach avoids changing a keyframe setting, codec, loop flag and URL all at once, which makes it harder to tell what affected the result. For output configuration, you can cross-check your command against the guide to using a YouTube stream key with FFmpeg for a continuous stream.
If you run an always-on channel, a local test is particularly useful before you leave the broadcast unattended. Keep the source file, probe result and known-good command together, and note what changed when a test succeeds. If the live process still stops after input validation, retain its complete log and distinguish input parsing from later stream processing. A retry is evidence only for the exact input and command tested; it is not a guarantee that a different file or URL will behave the same way.
A repeated input failure can also make a manually operated channel fragile overnight: someone has to be at the computer to notice and restart it. StreamNeo removes that particular need to keep your computer on for a file-based YouTube broadcast, but the source still needs to be a valid file and the channel setup still needs checking. Fix the media or list issue first rather than expecting a different way of running a broadcast to make invalid input readable.
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 “Invalid data found” mean my video file is corrupt?
Not by itself. The message means FFmpeg could not process input data, but that data might be a file, a URL response or a concat list arrangement. Probe the exact input and use the full log to distinguish among those possibilities.
Should I add -safe 0 to fix a concat loop?
Only if the evidence points to the concat demuxer rejecting paths and you understand the path-safety change. It does not repair a malformed list, a missing file or media that FFmpeg cannot read. Check every entry and its resolved path first.
Will remuxing or adding -fflags +genpts always fix it?
No. A stream-copy remux is relevant when readable packets need a fresh container, while timestamp generation is relevant when presentation timestamps are missing. Neither repairs every kind of invalid input; test a copy and probe the result before using it in the loop.
What should I share to identify the specific cause?
Share the exact FFmpeg command with stream keys and private credentials removed, the input type, and the complete log from command start through failure. Include the ffprobe output for the same file or URL. Without those details, the error alone cannot identify the fault.