YouTube Live says "No data is being received" — what it means and how to fix it
The message has four separate causes, and YouTube's own API defines exactly what it is reporting. This guide separates the cases instead of listing every fix at once.
You open YouTube Studio, the stream health panel says no data is arriving, and the preview stays black. Nothing in that message tells you which part of the chain broke — the encoder, the network, the settings, or the video file itself. That is the whole problem with it.
YouTube's Live Streaming API defines these states precisely, which makes the message far less mysterious than it looks. Below are the official definitions, then the four causes in the order worth checking, with the diagnosis for each. Every claim links to the source it came from.
What YouTube actually means by "no data"
YouTube Studio shows you a simplified badge, but underneath it the YouTube Live Streaming API exposes the real value. A stream carries a health status with four possible states, and the definitions are worth reading literally.
The four health states, quoted from Google's own reference:
- good — "There are no configuration issues for which the severity is warning or worse."
- ok — "There are no configuration issues for which the severity is error."
- bad — "The stream has some issues for which the severity is error."
- noData — "YouTube's live streaming backend servers do not have any information about the stream's health status."
The distinction almost every article gets wrong
Read that last definition again. noData does not mean your stream is broken. It means YouTube has nothing to report — no measurements, no diagnosis, nothing. That is a different condition from a stream that is arriving badly, which reports bad instead.
There is a second, separate field: the stream status. Its active state means "the user is receiving data via the stream", and inactive means "the user is not receiving data via the stream". So a stream can be inactive while its health reads noData, and those two facts come from different subsystems. Health tells you about quality; status tells you about presence. When people say "YouTube shows no data", they usually mean both at once — nothing is arriving, so there is nothing to measure.
This matters practically. If you see bad rather than noData, packets are reaching YouTube and the problem is quality — bitrate, dropped frames, keyframes. If you genuinely see noData, packets are not arriving at all, and no amount of encoder tuning will change that. The two need opposite fixes, which is why generic checklists waste your time.
Four places the stream can break
Between a video file and a YouTube viewer there are four links, and the message gives you no hint which one failed. Checking them in this order takes about two minutes and eliminates most cases immediately.
Is the encoder actually sending?
Open your encoder's own statistics before touching anything on YouTube's side. OBS shows a live bitrate readout in the status bar; if it reads 0 kbps, nothing is leaving your machine and YouTube is reporting the situation accurately.
- In OBS, check the bottom status bar for the outgoing bitrate and the dropped-frame counter.
- A bitrate of 0 kbps means the problem is entirely local — YouTube is not involved yet.
- A healthy bitrate with noData on YouTube's side points at the connection or the key, not the encoder.
Does the key match this broadcast?
A key that belongs to a different broadcast, or one that was regenerated after you copied it, produces exactly this symptom: the encoder connects happily and YouTube shows nothing.
- Compare the key in your encoder character by character against the Live Control Room.
- Regenerating a key in YouTube Studio invalidates the old one immediately.
- YouTube's own guidance for encoder startup errors is to get a new key and update the encoder.
Is the connection stable, not just fast?
Upload speed is not the same as upload stability, and streaming punishes the second far more than the first. A connection that benchmarks at 100 Mbps can still stall for two seconds at a time.
- Check the dropped-frame percentage in your encoder, not the speed-test result.
- Sustained dropped frames mean the path to YouTube is failing, not your hardware.
- Corporate networks, hotel Wi-Fi and some routers block or throttle RTMP on port 1935.
Is there actually a video playing?
The cause people check last and should often check first: the source itself ran out. An encoder with nothing to encode sends nothing, and YouTube reports exactly that.
- A playlist that reached its end stops producing frames while the encoder stays connected.
- A file that became unreadable mid-playback has the same effect.
- This is the dominant cause on unattended round-the-clock streams.
Wrong stream key or wrong endpoint
This is the most common cause and the easiest to rule out, which is why it belongs early rather than in a footnote. YouTube accepts the RTMP connection regardless of whether the key is valid for the broadcast you are watching — the handshake succeeds, and only then does the data go nowhere useful.
Two situations produce it repeatedly. The first is a regenerated key: you generated a fresh one in the Live Control Room but the encoder still holds the previous value. The second is a mismatch between a scheduled event and the persistent key, where the encoder streams to one and you are watching the other.
For the ingest URL itself and what each part of it means, the RTMP-to-YouTube guide breaks the whole string down. The short version: the URL is public and identical for everyone, so it is almost never the thing that is wrong. The key is the part that identifies you.
The network: dropped frames and stalls
When the encoder is clearly sending and the key is clearly right, the connection between you and YouTube's ingest servers is next. This is where diagnosis usually goes wrong, because people run a speed test, see a large number, and rule the network out.
A thread on the OBS Studio forums shows the trap clearly. The user had 150 Mbps down and over 100 Mbps up, and still could not hold a stream. Their logs recorded 21,876 dropped frames — 65.6% of the total — from insufficient bandwidth or connection stalls. The moderators concluded the fault lay somewhere along the path to YouTube's servers rather than in the encoder or the hardware.
That is the useful lesson: bandwidth and stability are different measurements, and only the second one keeps a stream alive. A link that averages 100 Mbps but stalls for two seconds every minute will drop frames continuously while every speed test you run comes back clean.
What to check when the network is the suspect:
- The dropped-frame percentage during a stall, not the average across the session.
- Whether the drops correlate with anything scheduled — backups, updates, another device.
- Whether port 1935 is filtered. If it is, switching to RTMPS on port 443 often walks straight through, since that is the port HTTPS already uses.
- Whether a VPN or a security appliance sits between the encoder and the internet.
YouTube's troubleshooting page offers a triage worth borrowing: if one viewer reports problems it is probably their connection, if several viewers on one network report them it is that network, and if viewers on different networks all report them the encoder or its uplink is at fault.
Settings YouTube rejects without telling you
Some encoder configurations are accepted at the protocol level and then produce an unusable stream. Nothing announces the problem; the connection simply does not turn into a watchable broadcast.
The keyframe interval is the one that catches people. YouTube's live encoder settings recommend a keyframe every 2 seconds and state plainly: do not exceed 4 seconds. Exceed it and YouTube cannot segment the stream properly, which surfaces as a broadcast that never starts or stalls at the first frame.
The settings YouTube publishes, with the values that actually matter:
- Video codec: H.264 is the required baseline; HEVC and AV1 are supported alternatives.
- Audio codec: AAC or MP3. For 5.1 surround over RTMP/RTMPS, only AAC works.
- Audio bitrate: 128 kbps for stereo, 384 kbps for 5.1 surround.
- Keyframe interval: 2 seconds recommended, 4 seconds is the hard ceiling.
- Bitrate, 1080p at 30 fps: 10 Mbps recommended; at 60 fps, 12 Mbps.
- Bitrate, 720p at 60 fps: 6 Mbps; 720p and below at 30 fps, 4 Mbps.
- Bitrate, 1440p: 15 Mbps at 30 fps, 24 Mbps at 60 fps.
- Bitrate, 2160p: 30 Mbps at 30 fps, 35 Mbps at 60 fps.
If you want those numbers worked out against your own resolution and upload capacity rather than read off a table, the bitrate calculator does it directly. And if the stream is running continuously rather than for an hour, treat the recommended figures as a ceiling rather than a target — the reasoning is in the bitrate guide for 24/7 streams.
When the source stalls instead of the connection
Everything above assumes there is video to send. On an unattended stream that runs for days, the more likely failure is that the source stopped producing frames while the encoder sat there perfectly connected.
This is the failure mode that separates a round-the-clock stream from a two-hour broadcast, and it is badly covered elsewhere because most troubleshooting advice is written for someone sitting at the machine watching it happen.
Four ways a source stalls while the connection stays up:
The playlist ended
The most mundane cause and the most common. A playlist without looping enabled plays to the end and stops. The encoder holds the connection open, sends nothing, and YouTube reports no data — accurately.
- Confirm looping is enabled rather than assuming it, and confirm it survived the last settings change.
- Check the total playlist duration against how long the stream had been running when it stopped. If those two numbers match, this is your answer.
- Prefer one long file or a genuinely looping playlist over a queue that terminates.
The file became unreadable mid-playback
A source on a network share or an external disk can vanish underneath a running encoder. The encoder does not always fail loudly; it can stall waiting for bytes that never arrive.
- Check whether the storage holding the file was still reachable at the moment the stream stopped.
- Avoid moving, renaming or re-encoding a file that is currently being streamed.
- On a network mount, a disconnect and a very slow read look identical to the encoder.
The source is being read too slowly
A subtler version of the same thing. If reading the video is slower than playing it, the encoder starves. It stays connected, output becomes intermittent, and stream health degrades before it disappears.
- Watch for output that stutters before it stops — that ordering points at the source, not the network.
- Reading several high-bitrate files from one disk or one network connection can saturate it.
- Copying the file to local storage before streaming removes the variable entirely.
The machine went to sleep or the process died
Anticlimactic but frequent. A desktop that suspends, an OS update that reboots, or an encoder killed by the system leaves the broadcast configured and empty.
- Disable sleep and automatic restarts on any machine expected to stream unattended.
- Check the system log for a restart at the timestamp the stream stopped.
- Any stream that has to survive days does not belong on a desktop you also use for other things.
Why reconnecting fast makes it worse
When a stream drops, the obvious response is to reconnect immediately, and most encoders offer an automatic retry with a short delay. On a continuous stream this can turn one brief outage into a permanent one.
YouTube does not free a broadcast's ingest slot the instant your encoder disappears. Reconnect before the previous session has been torn down and the new connection can be rejected — which triggers another retry, which arrives just as early as the last one. The result is a loop that looks like YouTube refusing to accept the stream at all, when the real problem is a retry that never waits long enough. We found this the hard way on our own infrastructure: a retry delay that sat right on the boundary of YouTube's teardown produced an endless reconnect cycle, and lengthening the delay fixed it outright.
If you are running your own encoder, give the retry a backoff that grows after each failure rather than a fixed short delay. A first retry after several seconds, then progressively longer, recovers from a genuine blip without hammering an endpoint that is not ready.
This is also the honest argument for not running the encoder yourself. Detecting the stall, waiting the right amount of time, reconnecting and resuming at the correct position is work that has to happen at four in the morning while nobody is watching. TheLoops does it as part of the service — the stream is monitored continuously and restarted automatically when it dies, without anyone being awake for it.
Stop debugging streams at 4 a.m.
Upload your video once. We keep it live around the clock, watch it continuously, and restart it automatically when something breaks.
Frequently asked questions
Not necessarily, though that is the most common single cause. YouTube's API defines noData as its servers having no information about the stream's health at all — which happens whether the key is wrong, the encoder stopped, the network failed, or the video source ran out. Check the encoder's outgoing bitrate first: if it reads 0 kbps the key is not the problem, because nothing is being sent in the first place.
Because speed and stability are different things, and streaming depends on the second. A documented case on the OBS forums had over 100 Mbps upload and still dropped 65.6% of frames to bandwidth shortfalls and connection stalls. Look at the dropped-frame counter during the failure rather than at a speed test taken afterwards.
On an unattended stream the usual answer is the source rather than the connection. A playlist reached its end, a file stopped being readable, or the machine slept or rebooted. Compare the total length of your playlist against how long the stream survived — if the two match, the playlist simply finished.