If 20 Mbps is your sustained upload speed, 1080p30 is the sensible place to start for YouTube Live. With H.264, use 10–12 Mbps when reliability matters, rather than assuming the full connection speed is available to the stream.
YouTube’s H.264 recommendation for 1080p30 is 14 Mbps. That can work on a stable 20 Mbps upload connection, but it leaves less room for variation than the lower starting range. A speed-test result is evidence to check, not a guarantee that your connection will hold that rate all night.
Confirm that 20 Mbps means upload
A connection advertised as “20 Mbps” may refer to download speed, upload speed, or a maximum speed shared across both. For live streaming, the important figure is the speed from your encoder to YouTube. A fast download connection does not compensate for a weak upload connection.
Run a speed test from the same location and network that will carry the broadcast. If you normally use Wi-Fi, test over that Wi-Fi. If the streaming computer will use Ethernet, test the Ethernet connection instead. Test at a time when you expect the channel to run, because a result during a quiet period may not represent the connection during the evening or overnight.
YouTube advises running a speed test to check your upload bitrate and testing before going live with audio and movement similar to the planned stream. You can follow its live encoder settings guidance rather than relying on the headline speed shown by your internet provider.
The figure you need is not merely the highest upload result. Look for a connection that remains steady while the encoder sends a constant stream. If the test shows 20 Mbps briefly but drops substantially during repeated tests, treat 20 Mbps as a peak, not as the capacity you should build the channel around.
Also consider what else is using the connection. Cloud backups, CCTV uploads, video calls, file transfers and other people’s devices can consume upload capacity without being obvious on the streaming computer. A channel that runs correctly when the network is otherwise idle may struggle when another device starts sending data.
YouTube’s recommendations depend on codec and format
YouTube’s live ingest recommendations vary with the codec, resolution and frame rate. The numbers below are for the video sent to YouTube, not for downloading or watching a finished video.
| Ingest format | AV1 or H.265 recommendation | H.264 recommendation |
|---|---|---|
| 1080p30 | 10 Mbps | 14 Mbps |
| 1080p60 | 12 Mbps | 17 Mbps |
| 720p30 | 6 Mbps | 8 Mbps |
| 720p60 | 6 Mbps | 8 Mbps |
| 1440p30 | 15 Mbps | 21 Mbps |
| 1440p60 | 24 Mbps | 34 Mbps |
These are recommendations, not a promise that every connection will deliver the same result. YouTube also lists lower minimum settings. For example, at 1080p30 it lists 4 Mbps for AV1 or H.265 and 5 Mbps for H.264. A minimum is not the same as a good operating target for a channel that needs to remain watchable overnight.
The codec matters because different codecs can produce different picture quality at the same bitrate. Your encoder, computer, streaming application and YouTube account may not offer the same codec choices. Select a codec your setup can encode consistently, then use the corresponding YouTube guidance rather than borrowing a number from another format.
For a simple devotional loop, bhajan channel or ambience station, 30 frames per second may be adequate. A channel with fast camera movement, sports footage or detailed motion may benefit from a higher frame rate, but that raises the bitrate requirement and reduces the headroom available on a 20 Mbps upload connection.
YouTube recommends constant bitrate encoding for live streams. It also recommends a two-second keyframe interval, with the interval not exceeding four seconds. Those encoder settings are separate from the bitrate itself, but they affect how consistently YouTube can process the incoming stream.
A practical 1080p30 starting point
For a measured and stable 20 Mbps upload connection, begin with 1080p30 at 10–12 Mbps when reliability is your priority. This is a cautious operating range, not a bitrate that YouTube separately prescribes as its H.264 recommendation.
At 10 Mbps, the nominal difference from a 20 Mbps upload result is about 10 Mbps. At 12 Mbps, it is about 8 Mbps. That remaining capacity can absorb some ordinary variation and other upload traffic. It does not make the stream immune to a line fault, severe congestion or a router problem.
If your encoder uses H.264, YouTube’s recommended 1080p30 bitrate is 14 Mbps. On a steady 20 Mbps upload connection, that leaves about 6 Mbps before accounting for variation and other traffic. The recommendation may be reasonable after testing, particularly when the image contains motion or fine detail, but it is not compulsory merely because your connection is labelled 20 Mbps.
A useful approach is to start at 10 Mbps, run a representative rehearsal, and inspect the result. If the picture needs more detail and the connection remains stable, move towards 12 Mbps. If the stream health warning appears, the upload rate fluctuates, or other traffic cannot be controlled, reduce the demand or choose a lower format.
Do not treat a lower bitrate as automatically poor quality. A relatively simple image, such as a still devotional background with gentle movement, may remain clear at a lower setting than a busy scene with text, leaves, water or camera motion. The right test is the actual material you intend to broadcast.
The same principle applies to pre-recorded channels. If you are sending a playlist rather than a camera feed, inspect the sections with the most movement and the smallest text. A still opening screen can hide problems that appear later in a scrolling news panel or animated music visualiser.
For a channel built around uploaded, pre-recorded material, StreamNeo removes the need to keep a home computer running solely to send that file continuously, while you still need to choose and test the stream settings that suit the source video and connection.
Why 1080p60 leaves less room
YouTube recommends 17 Mbps for H.264 at 1080p60. On a measured 20 Mbps upload connection, that leaves about 3 Mbps of nominal headroom. That is a narrow margin for a speed-test result that varies, another device uploading, or a brief period of congestion.
This does not mean 1080p60 cannot work. It means the connection and encoder need to behave consistently, and there is less room to respond when they do not. A stream can begin normally and later develop dropped frames when the connection changes or another upload starts.
For AV1 or H.265, YouTube lists 12 Mbps at 1080p60. That leaves more nominal room on a 20 Mbps upload connection, but only if your encoder can produce that codec reliably and your complete streaming path supports it. Codec availability and encoding performance should be verified in your own setup.
Frame rate is not just a quality label. It changes how many frames the encoder must send each second. Moving from 30 to 60 frames per second can make motion look smoother, but it also changes the bitrate recommendation and the amount of connection capacity you need to protect.
If your material does not contain meaningful motion, 1080p30 is often the more practical choice. For a local news loop with slides, a study channel with a mostly static layout, or a bhajan stream with limited animation, the extra frame rate may provide little benefit compared with the headroom it consumes.
You should also be cautious with 1440p on this connection. YouTube’s H.264 recommendation for 1440p30 is 21 Mbps, which is above a 20 Mbps upload result. Do not try to force that H.264 recommendation onto a connection that cannot meet it reliably. Lower the resolution or frame rate instead, or use a codec and setting that your tested setup can sustain.
For a broader discussion of the equipment and workflow required for demanding always-on streams, see this guide to the best cloud service for 24/7 4K 60fps YouTube Live streaming. The higher the format, the more important it becomes to verify the whole operating path rather than choosing a number from a table alone.
Allow for audio and network variation
Audio normally consumes far less bandwidth than the video, but it is still part of the stream. YouTube recommends 128 Kbps for stereo audio. That is small compared with a video setting measured in Mbps, yet it should not be confused with the total video bitrate or omitted from a careful capacity calculation.
If your encoder displays a combined bitrate, check whether the figure includes audio. If it displays video and audio separately, keep both within the capacity you have measured. The important point is to leave room for the complete outgoing stream, not only the number entered in the video field.
Network variation is usually more important than the audio allowance. A speed test is a snapshot, while a 24/7 channel needs the connection to remain usable across changing conditions. Congestion at the provider, Wi-Fi interference, router load and competing uploads can all reduce the available rate.
Where possible, use a wired connection between the encoder and router. This does not improve the service supplied by your internet provider, but it removes one source of variation between the encoder and the local network. If Ethernet is not practical, keep the encoder close to the access point and test from its actual position.
Keep non-streaming uploads away from the connection during the rehearsal and the live run. If you cannot control them, use a lower stream bitrate so that the channel does not depend on the full measured result. The suitable margin depends on how much your upload rate changes, so there is no honest universal reserve that guarantees stability.
Your source file can also affect the result. A video with a low frame rate or simple scenes may not need the same treatment as a fast-moving source. However, do not use a quiet section as your only test. Include the busiest scene, the loudest normal audio, transitions and any overlays that will appear during the real broadcast.
If an always-on stream begins buffering or dropping frames, the cause may not be the bitrate alone. This guide to fixing buffering on a 24/7 YouTube live stream from a VPS covers the wider checks worth making, including the sending environment and the path between the encoder and YouTube.
Set the encoder for a steady handoff
Choose the output resolution and frame rate first, then match the bitrate to that format. Avoid changing several settings at once during a diagnosis. If you move from 1080p30 to 1080p60 and raise the bitrate at the same time, it becomes difficult to tell which change affected the stream.
For the reliability-first 1080p30 starting point, use constant bitrate encoding and a two-second keyframe interval. YouTube says the keyframe interval should not exceed four seconds. Apply the setting in the encoder or streaming application, then confirm that it has actually been used in the output profile.
Use H.264 if it is the codec your setup handles reliably and your chosen software presents it clearly. If AV1 or H.265 is available, compare it using the relevant YouTube recommendation, but do not select it solely because its table value is lower. A codec that overloads the encoder can create a different failure even when the upload connection has spare capacity.
Watch the encoder’s own indicators during the test. A network problem may appear as dropped or skipped frames, while an overloaded computer may show encoding lag or render problems. These are different conditions and require different remedies.
If the stream is pre-recorded, check that the file’s frame rate and dimensions are compatible with the output settings. A streaming application may rescale or re-encode the file, which adds work even when the source itself is already prepared. Keep the workflow simple while testing so that the bitrate decision is based on a known configuration.
You can also review whether the same YouTube stream key is being used by more than one encoder. The guide on using the same YouTube stream key with OBS and FFmpeg is relevant when you are changing sending software or keeping a fallback ready. Do not use two active senders as an untested recovery plan.
Test the real broadcast and monitor it
Run a rehearsal with the same resolution, frame rate, codec, bitrate, audio and source material that you plan to use live. Test for long enough to encounter the normal changes in your connection and source, rather than stopping as soon as the preview appears.
YouTube’s stream-health information is more useful than the speed-test result alone. During the rehearsal and the live broadcast, watch for warnings, dropped frames and changes in the incoming bitrate. YouTube’s stream health help explains the checks available in the live control room.
A clean beginning is not proof of a clean night. Keep monitoring after the stream has started, particularly when the channel is new, the internet connection is shared, or the encoder is running on a computer that also performs other work. If you cannot watch continuously, arrange a practical alert or check schedule rather than assuming the stream will recover.
When a warning appears, record what happened before changing the settings. Did another device begin uploading, did the encoder show overload, or did YouTube report a connection issue? Lowering the video bitrate can help when upload capacity is the problem, but it will not repair an unstable encoder or a failing local network.
For a 20 Mbps upload connection, a sensible decision sequence is:
- Verify that the measured figure is upload speed from the actual streaming location.
- Start with 1080p30 at 10–12 Mbps when reliability matters.
- Use YouTube’s codec-specific recommendations as a reference, not as a guarantee.
- Rehearse with the real audio, movement and overlays.
- Raise the bitrate only when the test shows enough stable headroom.
- Prefer 1080p30 or a lower format if 1080p60 leaves too little margin.
This approach gives you a setting you can explain and reproduce. It also makes future troubleshooting easier because you know which part of the setup changed.
Choose reliability before resolution
The best bitrate is not the largest number your connection reaches once. It is the highest setting that your measured upload, encoder and source can sustain without repeated health warnings or dropped frames.
On a stable 20 Mbps upload connection, 1080p30 at 10–12 Mbps is a practical reliability-first starting range. H.264 at YouTube’s recommended 14 Mbps may be suitable after testing, while H.264 1080p60 at 17 Mbps leaves considerably less room for variation. AV1 or H.265 has different recommendations, but codec support and encoder performance still need to be tested.
If your priority is an uninterrupted devotional, ambience, study or news loop, a stable 1080p30 stream is usually more useful than a nominally sharper format that repeatedly loses connection. If the source demands more motion detail, improve the connection or reduce competing traffic before moving to a higher format.
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
Is 20 Mbps enough for 1080p YouTube Live?
It can be, if 20 Mbps is a sustained upload speed at the streaming location. For H.264, start around 10–12 Mbps at 1080p30 when reliability matters, then test before choosing whether to move towards YouTube’s 14 Mbps recommendation.
Can I stream 1080p60 on a 20 Mbps connection?
YouTube recommends 17 Mbps for H.264 at 1080p60, leaving about 3 Mbps from a measured 20 Mbps upload result. That is less forgiving of variation, so use it only after a representative test shows that the connection and encoder remain stable.
Should I use the speed-test result as my bitrate?
No. A speed test is a snapshot and does not guarantee sustained upload capacity during a live broadcast. Test with the actual audio, movement and encoder settings, then monitor YouTube’s stream health while live.
What if YouTube shows dropped frames?
First check whether the encoder is overloaded or the upload connection is falling short. Reduce the video bitrate or format if network capacity is the issue, stop competing uploads, and test again rather than assuming that increasing the bitrate will solve it.