If an FFmpeg loop stream to YouTube Live fails with Invalid data found when processing input, treat that message as a category, not a diagnosis. First establish whether FFmpeg can read the exact input and where the first failure occurs; review YouTube output settings only after that evidence is clear.
The error alone does not show that -stream_loop is responsible, nor does it identify one corrected command. To diagnose a particular run, you need the input, the full command, the FFmpeg build details and the complete log around the first error.
Capture the complete FFmpeg log
Start by saving the command exactly as run and all of FFmpeg’s output from the beginning of the process. Do not copy only the last line from a terminal or a screenshot of the final failure. Earlier lines often show whether the program opened the input, what streams it detected, and which operation was underway when something failed.
Keep the original command intact while investigating. If you change the input, add an option or alter an encoder setting before capturing the baseline, it becomes harder to tell which change affected the result. Record the working directory too if the command uses relative file paths, and replace any private stream keys or credentials with a placeholder before sharing logs publicly.
When FFmpeg writes to a log file, a useful diagnostic capture is:
ffmpeg -report [the rest of your original arguments]
This is a way to preserve a report, not a replacement for reviewing the command and its console output. The bracketed phrase is explanatory; do not paste it as a literal argument. Alternatively, copy all terminal output into a text file. Make sure the capture includes the input argument and the lines immediately before the first occurrence of Invalid data.
Read the log in order, looking for the first warning or error rather than assuming its last line explains everything. Note which input is named, whether a container or stream description appears, and whether the failure happens before output is opened or after encoding begins. Later messages may be consequences of an earlier failure. If you ask someone else to help, provide the redacted command, ffmpeg -version, the input’s ffprobe output and the relevant complete log, not just a paraphrase.
What the invalid-data message tells you
FFmpeg’s error reference associates “Invalid data found when processing input” with an invalid-data error category. That wording identifies the kind of error being reported; it does not name the specific bad bytes, file, protocol or processing stage in your run. The FFmpeg error reference documents the category, but it cannot inspect your source media or command.
The word “input” should not be used to jump straight to a conclusion either. Your log and command context are what tell you which input FFmpeg means and what it was doing. An FFmpeg process can open media, parse its container, decode streams, filter frames and prepare output. The final text, on its own, does not tell you which of those steps needs attention.
A failed probe can be consistent with several conditions: the bytes may be incomplete or damaged, the content may not be media, or the format may not be supported by that build or demuxer. Those are possibilities to test, not claims about your particular file. Likewise, a source that probes successfully can still fail later during decoding, filtering or output setup.
Do not blame -stream_loop merely because it appears in the command. It controls repeated input reading, but the sources available for this diagnosis do not establish that this option causes the invalid-data error or that removing it fixes it. First locate the failure in the log; then test one change at a time with the same input and a saved baseline.
Probe the exact input with ffprobe
Use ffprobe against the same file or URL supplied as FFmpeg’s input. The first check can be simple:
ffprobe -hide_banner "INPUT"
Replace INPUT with the exact input path or address. Preserve the quotation marks when the value contains spaces or characters that the shell treats specially. If the production command reads a URL, probe that URL rather than a local copy unless the local copy is exactly what the command uses; different inputs can behave differently.
Check whether the probe identifies a container and lists the expected video and audio streams. Compare what it reports with what you believe the file contains. If a devotional video should include a picture and an audio track but only one stream is reported, record that discrepancy rather than immediately changing YouTube’s bitrate. If the command uses a network address, note whether the probe can reach and parse it in the same environment where FFmpeg runs.
If probing fails, check basic access and input identity before adjusting output options. Confirm that the path is correct, the file is fully present, the process can read it, and the input is actually media in a format the installed build can inspect. For a URL, also consider whether it is a direct media source or a page that merely points to media, and whether the protocol and access method are supported. These checks narrow the possibilities; they do not prove a single cause.
If the probe succeeds, save its output and return to the original FFmpeg log. A successful probe is useful evidence about the input, but it does not prove that every packet can be decoded or that later filtering and output configuration are sound. The practical sequence is to establish what the probe sees, then identify the first failing stage in FFmpeg’s full run. The FFmpeg Cookbook troubleshooting note also recommends probing as an input check; use it as general troubleshooting context, not as a diagnosis of your case.
Inspect the input and reported streams
Read the probe output for format, duration where available, stream types, codec names, dimensions, frame rate and audio properties. Do not treat any one field as a complete health check. A container may be recognised even when some media data is missing, and a listed stream may still encounter a decode error when FFmpeg reads further into it.
Compare the report with the exact source you intend to loop. Check that the file size and duration are plausible for the expected asset, that the reported video dimensions match the intended version, and that the audio stream is present if the programme needs sound. If the input was copied or downloaded, verify the copy is complete and compare it with the original when possible. A mismatch points to an input or transfer investigation, not automatically to a YouTube encoder adjustment.
For a more detailed stream view, use:
ffprobe -hide_banner -show_format -show_streams "INPUT"
This prints format and stream information that you can compare with the FFmpeg log. You can retain it with the diagnostic bundle. If you share it, redact private URLs and credentials just as you would from the FFmpeg command.
If the media is readable but the run fails while decoding or filtering, note the stream index and any frame or timestamp mentioned near the first error. Avoid treating a long-running loop as evidence that the source is necessarily clean: a failure may only appear when the process reaches particular data. Conversely, an error that occurs immediately while opening the source calls for a different line of investigation than one that follows many successfully processed frames.
Operators building a continuous programme from recorded lessons may find it useful to separate content preparation from broadcast troubleshooting; the recorded calculus channel workflow discusses the broader planning context. Here, keep the test narrow: the exact input in question, its probe report and the first failing point in the log.
Check the FFmpeg build and command context
Capture the installed version and build configuration with:
ffmpeg -version
Include the output when asking for help. FFmpeg builds can differ in enabled libraries, demuxers, decoders and protocol support, so advice based on a different build may not match what your command can read. The version output does not itself explain the error, but it establishes the environment in which the result occurred.
Then inspect how the command is assembled. Confirm which argument is the input and which options apply to it, whether the path or URL is quoted correctly, and whether options intended for input or output are placed in the right part of the command. FFmpeg command order matters because many options apply to the next input or output. Do not rearrange several options at once without preserving the original and testing a clearly defined change.
For looped playback, record the exact placement and value of -stream_loop, but do not infer causation from its presence. If the log shows a problem opening or parsing the source before any repeated reading is relevant, investigate that evidence first. If it shows successful processing and a later problem, use the named stage and surrounding messages to guide a controlled test. A test without -stream_loop can be informative only if it changes one variable and you compare what actually happens; it is not a universal fix.
Also distinguish local files from network inputs. A local file depends on the path and readable bytes available to the process. A network input may depend on protocol handling, address validity and access from the machine running FFmpeg. The RTSP protocol guide is relevant if your source is an RTSP stream, but an RTSP input is not interchangeable with a video file and should be diagnosed as the actual source type.
Review outgoing encoder settings separately
Once the input is readable and the log points to output preparation or YouTube ingest, review the outgoing stream against YouTube’s current guidance. YouTube’s live encoder settings page covers protocol, codecs, frame rate, keyframes and bitrate. It recommends RTMPS, lists H.264, H.265/HEVC and AV1 video, and recommends a two-second keyframe interval not exceeding four seconds. Check the current page for details that apply to your chosen codec and mode.
For H.264, the published bitrate recommendations vary with resolution and frame rate. The table below reproduces the minimum and recommended figures in Mbps from YouTube’s guidance; it is a reference for outgoing configuration, not a repair for an input parsing error.
| Output resolution and frame rate | Minimum bitrate | Recommended bitrate |
|---|---|---|
| 4K/2160p at 60 fps | 14 Mbps | 50 Mbps |
| 4K/2160p at 30 fps | 11 Mbps | 42 Mbps |
| 1440p at 60 fps | 8 Mbps | 34 Mbps |
| 1440p at 30 fps | 7 Mbps | 21 Mbps |
| 1080p at 60 fps | 6 Mbps | 17 Mbps |
| 1080p at 30 fps | 5 Mbps | 14 Mbps |
| 720p at 60 fps | 3 Mbps | 8 Mbps |
| 720p at 30 fps | 3 Mbps | 8 Mbps |
| 480p at 30 fps | 0.4 Mbps | 4 Mbps |
| 360p at 30 fps | 0.4 Mbps | 4 Mbps |
Choose the row that matches the actual output, not simply the source file’s resolution. A 1080p source resized to 720p should be assessed as a 720p stream. YouTube also advises using constant bitrate encoding and a representative test stream, with enough available upload capacity for the chosen output. A speed test can help you assess the connection, but it does not confirm that the input file is valid.
Check audio as well as video. YouTube lists AAC or MP3 audio, and its page includes additional recommendations such as progressive scan, square pixels and colour guidance for SDR. Exact settings depend on the codec and output mode, so use the official page rather than treating a generic command copied from another workflow as authoritative. For a deeper look at H.265-specific considerations, see the pre-recorded H.265 encoder settings guide.
Keep the two questions separate: can FFmpeg read and process this input, and is the stream it sends configured appropriately for YouTube? A bitrate mismatch or keyframe interval deserves attention when the log or YouTube’s health indicators point to ingest quality. It does not explain an input error by itself. If maintaining a computer-driven broadcast is the operational difficulty after the file and channel are ready, StreamNeo removes the need to leave your own computer running for that continuous file stream.
Retest with evidence from the log
Make the smallest test that addresses the first failure you found. If ffprobe cannot identify the input, investigate the file, access or protocol before altering bitrate. If probing succeeds but FFmpeg fails during decoding, test the relevant input or processing path while preserving the original settings. If FFmpeg reaches output and YouTube reports a stream issue, then compare the actual outgoing codec, resolution, frame rate, bitrate mode, keyframe interval and protocol with the current encoder guidance.
For each attempt, save the exact command, version output and complete log. Note what changed and whether the first error moved, disappeared or stayed the same. Avoid changing input, loop behaviour, codec, bitrate and resolution together: even if the next run works, that leaves you without evidence of which change mattered. A short representative test can help isolate a stage, but it cannot establish that a long-running broadcast will behave identically under every condition.
If you still need a precise diagnosis, provide the redacted command, ffmpeg -version, the ffprobe output for the exact input and the full log around the first error. Include whether the source is a local file or a network address, and say when the error occurs relative to opening the input and starting output. Without those details, a specific corrected command would be guesswork.
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 -stream_loop cause “Invalid data found when processing input”?
The error text does not establish that -stream_loop caused the failure, and the evidence here does not support blaming it. Check the complete log and probe the exact input first; test loop behaviour only as a controlled change if the log makes that relevant.
What should I send when asking for help?
Send the exact command with private keys and credentials removed, the output of ffmpeg -version, the ffprobe report for the same input and the complete FFmpeg log around the first error. Also say whether the input is a file or URL and when the failure appears in the run.
If ffprobe succeeds, is the input definitely fine?
No. A successful probe shows that FFmpeg can recognise reported format and stream information, but it does not prove that every packet will decode or that later filtering and output will work. Use the full FFmpeg log to find where processing first fails.
Should I change the YouTube bitrate to fix this message?
Not on the basis of this message alone. First establish whether the input is readable and which stage emits the error; then review YouTube’s current encoder recommendations if the evidence points to outgoing configuration or ingest health.