When YouTube says the encoder is not sending enough data, treat it as a delivery-continuity warning, not a diagnosis. Check the exact Live Control Room message, your FFmpeg output, the stream settings and the connection before changing pacing flags.
The wording can point to interruptions in the video reaching YouTube, but it does not tell you whether the cause is upload capacity, an unsuitable configuration or encoding that is falling behind. Work through those possibilities in order, change one relevant setting at a time, and test again.
What “not receiving enough video” means
YouTube’s Live Streaming API describes this health state as “YouTube is not receiving enough video to maintain smooth streaming.” That tells you what YouTube observes at ingestion: video is not arriving in a sufficiently steady way to maintain a smooth stream. It does not tell you why.
A valid FFmpeg command can still send an irregular stream. The connection might be unable to carry the configured bitrate consistently; the chosen resolution or frame rate might be more than the connection can sustain; or the encoder might not be producing frames quickly enough. A different configuration issue can also trigger a separate warning. The message is a starting point for checking, rather than proof of any one cause.
This distinction matters when a channel is expected to run unattended. If a devotional loop or local news stream drops frames overnight, inserting a flag because it appears in a search result may obscure the real issue. First find where continuity is breaking: in the encoder’s output, the network path or the stream’s configuration.
If the stream is built around a prerecorded file, also keep the input format in view. A file-based loop and a live camera feed have different timing needs. The plain-language guide to video format for 24/7 streaming explains the role of H.264 and AAC in a common upload workflow; neither format alone confirms that a live stream is arriving steadily.
Read the specific Live Control Room messages
Open the stream’s Live Control Room and note the exact health warning, any additional error text and when each message appeared. YouTube error messages include timestamps, and unresolved errors can continue to appear. The timestamp can help you compare the warning with an encoder restart, a network change or a particular point in your programme.
Do not treat every red or yellow health notice as a paraphrase of “not enough data”. YouTube documents distinct error categories, including bitrate, codec, audio and video settings, resolution and keyframe frequency. An explicit bitrate or resolution error gives you a more targeted lead than the general smooth-streaming health state. Read the YouTube Help guide to live streaming error messages alongside the Live Streaming API health-status descriptions.
Write down the warning exactly as shown. If several messages appear, record all of them rather than choosing the one that seems easiest to fix. For example, a general continuity warning alongside a resolution error suggests checking both the stream configuration and delivery, not changing a pacing flag and stopping there.
Use the sequence of timestamps as evidence, not as a root-cause report. If the warning appears repeatedly during a complex section of a loop, note that. If it starts after a configuration change or reconnect, note that too. These clues narrow your next test, but they do not by themselves prove that a particular file, setting or piece of equipment is responsible.
Check FFmpeg output and real-time performance
Next, look at FFmpeg’s output while the problem is occurring. For a live encode, check whether reported encoding speed stays close to real time and whether the process reports errors, reconnects or other interruptions. A syntactically valid command is not enough if the process cannot keep up with the rate at which live input arrives.
Avoid jumping from a slow-looking status line to a hardware diagnosis. Check what FFmpeg actually reports and compare it with the input and output you configured. A complex scene, a change in input behaviour or an encoding setting may affect performance, but the warning alone does not establish that the processor or graphics hardware is overloaded. Keep notes on when speed changes and whether the health warning follows.
The distinction between file input and live capture is especially important for -re. FFmpeg documents -re as a real-time input read-rate control: it reads an input at its native rate, effectively 1×. A prerecorded file can otherwise be read faster than real time, so pacing file input may be useful in a live-output workflow. But that does not make -re a universal repair for a live camera, network congestion, a wrong bitrate or encoding that cannot keep up.
FFmpeg cautions against using a low read rate with an actual capture device or live stream. Confirm the input type and understand how your command handles it before adding or removing -re. The FFmpeg command-line documentation describes the option; consult the documentation for the build and workflow you use. Do not add a pacing flag simply because YouTube reports insufficient video.
Compare bitrate and resolution settings
Check your configured codec, resolution, frame rate, bitrate and keyframe interval against the YouTube ingest settings for that codec. YouTube’s current live encoder settings and bitrate recommendations include H.264, H.265/HEVC and AV1 video options, and recommend constant bitrate encoding (CBR). The appropriate bitrate depends on the codec, resolution and frame rate; there is no single target for every channel.
For reference, YouTube’s H.264 recommendations include these combinations:
| Output setting | YouTube’s recommended H.264 bitrate |
|---|---|
| 720p at 30 fps | 8 Mbps |
| 1080p at 30 fps | 14 Mbps |
| 1080p at 60 fps | 17 Mbps |
These are YouTube’s published encoder recommendations, not guaranteed upload-speed requirements or a promise of smooth delivery. The same settings page lists different recommendations for AV1 and H.265/HEVC: for example, 10 Mbps at 1080p and 30 fps, and 12 Mbps at 1080p and 60 fps. Match the row to the codec and frame rate you actually send; do not copy a number across codecs without checking.
YouTube recommends a two-second keyframe frequency and specifies a maximum interval of four seconds in its current guidance. Confirm what your command sends, and compare it with the chosen ingestion settings. A keyframe or GOP problem can generate its own ingestion error; that is different evidence from a general “not receiving enough video” warning. The distinction is useful: if Control Room reports a keyframe issue, investigate that setting directly rather than assuming all continuity messages mean the same thing.
If your configuration is more demanding than the connection can reliably carry, lower the resolution or choose a lower-bitrate profile and test. YouTube’s error guidance advises considering a lower resolution when available bandwidth is insufficient. A low-bandwidth codec and bitrate guide can help you reason through the trade-off, but use the current YouTube settings page for the supported recommendations that apply to your stream.
Test available upload capacity
Test the upload connection from the place and network path that will carry the stream. YouTube recommends running a speed test and choosing a quality that produces a reliable stream for the connection. A result taken at another location, on another connection or at a different time may not describe the capacity available during your broadcast.
Compare the measured upload capacity with the bitrate you intend to send, but do not assume that a headline speed-test result will be available to the stream continuously. Other devices and services may use the connection; upload capacity can also vary. Leave room for that variation rather than setting the stream to consume nearly all of the measured capacity. The test is a practical check, not a guarantee that the connection will remain steady.
For instance, if a 1080p configuration repeatedly produces health warnings while your connection test offers little headroom above the configured bitrate, try a lower resolution and bitrate. Keep the encoder and programme otherwise unchanged, then compare the health result. If warnings continue at a lower load, revisit FFmpeg output and other error messages instead of repeatedly lowering settings without a hypothesis.
A connection used for a long-running channel also needs to be available consistently, not just fast in one short test. If several streams, backups or household devices share the upload, account for that before assigning the full measured capacity to one broadcast. For an India-based church using limited broadband, the continuous-stream setup guide for OBS and limited broadband covers the practical constraints of choosing a sustainable setup. The same principle applies to FFmpeg: choose a configuration that fits the connection you have, then observe it under representative conditions.
Choose a reliable stream quality
The highest resolution is not necessarily the best choice for an always-on channel if it leaves no room for variation in the connection or encoder. A lower, steady stream can serve a devotional playlist, study session or local information loop better than a higher setting that repeatedly interrupts. Choose a quality that is workable for the content and can be sustained by the upload path and encoder together.
Make the decision using the whole chain. A bitrate that fits the network still needs an encoder able to produce the output in real time. A capable encoder still needs a stable connection. A codec and frame rate should fit both the viewing purpose and the settings supported by YouTube. There is no reason to make the picture heavier than the content needs: a mostly static temple image and a sports camera do not place the same demands on the viewer’s sense of motion, even though the configured output must still be valid and tested.
For a file-based station, the burden of keeping a local computer switched on and watching for interruptions can be inconvenient. StreamNeo addresses that specific operational pain by turning an uploaded file into a YouTube live stream that can run while your computer is off. It does not change YouTube’s ingest requirements or make an unsuitable file or setting correct, so verify the stream health and configuration whichever workflow you use.
If you use a local FFmpeg workflow, keep a known-good configuration and change only one variable at a time. Lowering resolution, lowering bitrate, changing codec and changing pacing simultaneously can make a warning disappear without showing which change mattered. A simple log of the old setting, the single change and the resulting health state makes the next troubleshooting step more useful.
Test before the event and monitor health
Run a test with the actual audio and representative video movement before relying on the stream for an event or overnight schedule. A static image with quiet audio may not exercise the same path as a moving visual and a full soundtrack. YouTube recommends testing before the event and monitoring stream health during it; use that time to watch both Live Control Room and FFmpeg output.
Begin with a baseline: note the codec, resolution, frame rate, bitrate and keyframe interval; note the exact warning, if any; and save the relevant FFmpeg output. Then make one change with a reason. If the stream has a specific bitrate error, verify the configured bitrate. If capacity appears limited, test a lower output setting. If FFmpeg reports that it is not keeping pace, investigate the encode path before asking the network to carry more data.
During the test, look for recurring warning timestamps, reconnects, changes in FFmpeg’s reported speed and any explicit configuration errors. A brief clean interval does not establish that the same settings will remain stable over a long session. Continue to monitor health during the stream, especially after a change to the file, encoder command, network or YouTube settings.
If a stream does fail, recover first and investigate the evidence afterwards. The guide to recovering a YouTube radio stream when FFmpeg exits addresses process recovery; automatic restart can restore a broadcast, but it does not identify or correct the cause of a delivery-continuity warning. Keep recovery and diagnosis as separate tasks.
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 warning mean I should add -re?
Not by itself. -re controls how FFmpeg reads input in real time and can be relevant when a prerecorded file is sent as live output. Check whether your input is a file or an actual live source, then inspect the health details, FFmpeg output and configured stream before changing it.
Is the YouTube bitrate recommendation the upload speed I need?
No. The recommendation is an encoder bitrate for a particular codec, resolution and frame rate; it is not a guarantee or a universal speed-test threshold. Test the actual upload connection, leave room for variation and select a stream quality that remains reliable.
Should I lower resolution when YouTube reports insufficient video?
Consider it if your upload capacity cannot reliably support the current configuration, as YouTube advises for insufficient bandwidth. First check for a specific resolution or bitrate error and compare the configured settings with the relevant YouTube recommendations. Change one setting and retest.
Can this message alone tell me whether FFmpeg or my connection is at fault?
No. It describes video that is not reaching YouTube steadily enough, not the underlying cause. Use the exact Control Room messages, FFmpeg’s reported performance, the stream configuration and an upload test to narrow it down.