Bitrate settings for a 24/7 YouTube stream
YouTube publishes one set of numbers for live streaming. They were written for a broadcast that ends. A stream that never stops needs them read differently.
Almost every bitrate article repeats YouTube's recommended table and stops there. The table is correct, but it answers a question most 24/7 streamers are not asking: what should I send for a broadcast I am sitting and watching?
A stream that runs for weeks is a different problem. It has to survive the worst minute of every day rather than perform well on average, and the content is usually a loop rather than live action. Both facts push the right answer downward from the recommended figure. Here is the reasoning, with YouTube's published numbers as the starting point.
YouTube's official numbers
These come from YouTube's live encoder settings page. They are recommendations for H.264, the codec YouTube requires as a baseline.
Recommended video bitrate by resolution and frame rate:
- 2160p (4K) at 60 fps — 35 Mbps
- 2160p (4K) at 30 fps — 30 Mbps
- 1440p at 60 fps — 24 Mbps
- 1440p at 30 fps — 15 Mbps
- 1080p at 60 fps — 12 Mbps
- 1080p at 30 fps — 10 Mbps
- 720p at 60 fps — 6 Mbps
- 720p and below at 30 fps — 4 Mbps
Audio is simpler: 128 kbps for stereo, 384 kbps for 5.1 surround. AAC or MP3 are accepted, but 5.1 over RTMP or RTMPS requires AAC specifically.
Treat the video figures as the top of a range rather than a target. YouTube re-encodes everything it receives, so sending more than the recommended number does not buy proportionally better output — it mostly buys a larger, more fragile stream.
What changes when the stream never ends
A two-hour broadcast succeeds if your connection is good for two hours. A continuous stream succeeds only if your connection is good during its worst moment across weeks — and every connection has a worst moment.
Three reasons to sit below the recommended figure
- Headroom for the bad minutes. Backups run, someone streams a film, the provider reroutes traffic. A stream configured at the edge of your capacity drops frames the moment anything else happens; one configured well below it simply keeps going.
- Sustained load, not peak load. Encoding for an hour and encoding for three weeks are different demands on the same hardware. Thermal throttling and memory pressure appear on timescales that a short test never reaches.
- Looped content compresses better. Most 24/7 streams show ambient footage, a static scene, slow visuals or a music visualiser. That material needs far fewer bits than fast motion, and spending the full recommended bitrate on it changes nothing a viewer can see.
A practical rule that holds up well: pick the recommended figure for your resolution, then send around 70–80% of it, and make sure that number is comfortably under half of your measured sustained upload. If those two constraints disagree, the connection wins.
This is also the argument for streaming from infrastructure rather than a home connection. A stream sent from a data centre is not competing with anyone's evening video calls.
CBR, VBR and why it matters more here
Constant bitrate sends a steady stream of data regardless of what is on screen. Variable bitrate spends more on complex frames and less on simple ones. For file encoding VBR is usually the better choice; for live streaming the reasoning inverts.
Live ingest is sized around a predictable rate. Under VBR, a sudden complex scene produces a spike that can exceed what the connection can carry at that instant, and the result is dropped frames rather than a slightly larger file. CBR removes that class of failure by never spiking.
On a looped 24/7 stream the case for CBR is stronger still, because you already know the content. There is no unexpected explosion of motion to budget for — the same footage plays again and again — so the flexibility VBR offers buys nothing while its risk remains.
If your encoder exposes a buffer size alongside the bitrate, setting it equal to the bitrate is the conventional starting point and keeps the output close to genuinely constant.
Keyframes and the 4-second ceiling
YouTube's encoder settings state the keyframe interval plainly: 2 seconds recommended, and do not exceed 4 seconds. This is not advisory in the way bitrate is. Beyond 4 seconds YouTube cannot segment the stream properly, and the broadcast may never start at all.
The temptation on a long-running stream is to raise the interval, since fewer keyframes means fewer bits spent on them. Resist it. The saving is small, the ceiling is hard, and a stream that has run for two weeks is an expensive place to discover a segmentation problem.
Two seconds is the right answer for essentially every 24/7 stream. It sits inside the limit with room to spare and it keeps the delay before a new viewer sees a picture short.
If a stream is failing to start and the settings otherwise look correct, the keyframe interval is one of the first things worth checking — it produces symptoms that look nothing like a keyframe problem. The no-data guide covers the rest of that diagnosis.
Choosing resolution for looped content
Resolution drives bitrate more than any other setting, so choosing it honestly is the biggest saving available. The question is not what your source file is, but what the content actually needs.
How the common 24/7 categories behave:
- Static or near-static scenes — a fireplace, an aquarium, a countdown, a lofi loop with a still image. 1080p at 30 fps is generous; 720p is frequently indistinguishable to a viewer.
- Slow ambient footage — city walks, nature, spa visuals. 1080p at 30 fps with a moderate bitrate holds up well.
- Fast motion — gaming highlights, sport, anything with rapid cuts. This is the one category where the recommended figure is genuinely earned.
- Audio-led streams — radio, talk, music with minimal visuals. Spend the budget on 128 kbps stereo audio and drop the video resolution without hesitation.
60 fps deserves particular scepticism. It roughly doubles the recommended bitrate and it does nothing for a static scene. Unless the content genuinely moves fast, 30 fps is the better trade.
You can work this through against your own numbers with the bitrate calculator, and check the resulting file sizes with the file size calculator if storage is a factor.
Working out your own number
Four steps, in order. The whole thing takes about ten minutes and it is worth doing properly once rather than guessing repeatedly.
Measure sustained upload, not peak
Run an upload test several times across a day, including your busiest hour. The lowest result is the one that matters — that is the figure the stream has to survive.
- Test in the evening if the connection is shared with a household.
- Note the lowest sustained figure rather than the best one.
- Wired is materially more stable than Wi-Fi for a continuous stream.
Halve it
Set your ceiling at half of that lowest measurement. Video is not the only thing using the connection, and a stream running at 90% of capacity has nowhere to go when anything else appears.
- Half is a working rule, not a law — but going above 70% is asking for dropped frames.
- Remember audio adds 128 kbps on top of the video figure.
- Overhead from the protocol itself is small but not zero.
Match it against the resolution you actually need
Compare that ceiling against YouTube's recommended figure for the resolution the content deserves, and take the lower of the two.
- Static content: consider 720p at 30 fps and stop worrying about the connection.
- 1080p at 30 fps at roughly 7–8 Mbps is a reasonable continuous target.
- If the connection dictates a lower resolution, lower the resolution rather than under-feeding a higher one.
Run it for a full day before trusting it
A configuration that works for ten minutes tells you nothing. Let it run through a peak period and check the dropped-frame counter afterwards.
- Any sustained dropped frames mean the bitrate is still too high for the connection.
- Check whether drops cluster at particular times — that points at something scheduled.
- Only change one variable at a time, or you will not know what fixed it.
Or skip the tuning entirely
Upload your video and we encode and stream it from our infrastructure — no home upload limit, no thermal throttling, no dropped frames at 9 p.m.
Frequently asked questions
YouTube recommends 10 Mbps for 1080p at 30 fps. For a continuous stream, around 7–8 Mbps is a better target: it leaves headroom for the moments when your connection is busy, and on the static or slow-moving content typical of 24/7 streams the difference is not visible. The hard constraint is that your chosen figure should sit under half of your lowest measured upload speed.
No. YouTube re-encodes everything it receives, so past a certain point extra bits are discarded rather than displayed. What a higher bitrate reliably buys you is a stream that is more likely to drop frames when the connection wobbles. On looped content the practical ceiling arrives well below YouTube's recommendation.
CBR. Variable bitrate spikes on complex scenes, and a spike that exceeds what your connection can carry at that instant becomes dropped frames. For a looping stream the content is known in advance, so VBR's flexibility gains nothing while its risk stays.