If you send a pre-recorded video to YouTube as a live stream, choose the bitrate for the live encoder output, not for the file stored on your computer. For 1080p, YouTube’s current live targets are 10 Mbps at 30 fps or 12 Mbps at 60 fps with AV1 or H.265, and 14 Mbps at 30 fps or 17 Mbps at 60 fps with H.264.
Those figures only describe the incoming live feed. Your upload connection must sustain the video bitrate, audio and other traffic with roughly 20% upload headroom. If it cannot, lower the outgoing resolution or frame rate, then test the complete stream and watch YouTube’s health messages.
Choose the outgoing resolution, frame rate and codec
A pre-recorded source can be large, detailed and encoded at a high bitrate, but that does not mean you should send it to YouTube at the same settings. Your encoder reads the file, decodes it and creates a new live output. The settings that matter at YouTube’s ingest point are the resolution, frame rate and codec of that output.
Start with the viewing experience you actually need. A devotional channel showing a mostly static image with changing text may not benefit from 60 fps. A local traffic loop with moving footage may look smoother at 60 fps, but it also needs more outgoing bitrate. A study channel with slides and a talking-head window may be well served by 1080p30.
The codec matters as well. YouTube’s live guidance lists H.264, H.265/HEVC and AV1. At the same resolution and frame rate, its recommended bitrate differs by codec, so do not copy a H.264 value into an AV1 or H.265 encoder without checking which codec is selected.
For most operators, the practical decision is not “What is the highest setting my source file supports?” It is “What output can my connection and encoder maintain continuously?” A stable 720p30 stream is more useful than a 1080p60 stream that repeatedly loses connection or falls behind.
YouTube recommends allowing it to detect encoder settings by default. If you need to choose them manually, use a custom stream key and enable the relevant manual resolution settings in YouTube Studio. The official live encoder settings guide explains the current controls and supported combinations.
Use YouTube’s live bitrate recommendations
The following table is for the bitrate sent to YouTube as a live stream. The minimum columns are not a promise that every connection will behave well at that rate. The recommended columns are YouTube’s guidance for the matching incoming resolution, frame rate and codec.
| Incoming resolution and frame rate | AV1 / H.265 minimum | AV1 / H.265 recommended | H.264 minimum | H.264 recommended |
|---|---|---|---|---|
| 2160p, 60 fps | 10 Mbps | 35 Mbps | 14 Mbps | 50 Mbps |
| 2160p, 30 fps | 8 Mbps | 30 Mbps | 11 Mbps | 42 Mbps |
| 1440p, 60 fps | 6 Mbps | 24 Mbps | 8 Mbps | 34 Mbps |
| 1440p, 30 fps | 5 Mbps | 15 Mbps | 7 Mbps | 21 Mbps |
| 1080p, 60 fps | 4 Mbps | 12 Mbps | 6 Mbps | 17 Mbps |
| 1080p, 30 fps | 4 Mbps | 10 Mbps | 5 Mbps | 14 Mbps |
| 720p, 60 fps | 2 Mbps | 6 Mbps | 3 Mbps | 8 Mbps |
| 720p, 30 fps | 2 Mbps | 6 Mbps | 3 Mbps | 8 Mbps |
| 480p, 30 fps | 0.3 Mbps | 3 Mbps | 0.4 Mbps | 4 Mbps |
| 360p, 30 fps | 0.3 Mbps | 3 Mbps | 0.4 Mbps | 4 Mbps |
For the common 1080p choices, this means 10 Mbps at 30 fps and 12 Mbps at 60 fps with AV1 or H.265. With H.264, the corresponding recommended values are 14 Mbps and 17 Mbps. These are YouTube Help’s live-ingestion recommendations, accessed in October 2026, rather than separate recommendations for uploading a video file.
Use the row that matches what your encoder is actually sending. If your original file is 1080p60 but you configure the encoder to output 1080p30, use the 1080p30 row. If you choose H.264 because your encoder or workflow requires it, use the H.264 column rather than the AV1 or H.265 column.
The same principle applies to 4K. The table shows substantially higher recommended rates for 2160p, especially with H.264. YouTube says 4K streams are optimised for quality and do not offer its low-latency option. If your channel does not need 4K detail, 1440p or 1080p may be easier to operate through a long unattended broadcast.
YouTube automatically transcodes a live feed into versions suited to different viewers and network conditions. You generally do not need to send one bitrate for a phone viewer, another for a desktop viewer and another for a television. Send one properly configured live feed and let YouTube create the playback versions.
Distinguish the live output bitrate from the file bitrate
The bitrate shown in a file’s properties describes how that file was encoded and stored. It is not automatically the bitrate that YouTube receives during a live broadcast. A file might have been exported at a high bitrate for editing, compressed for storage, or encoded with variable bitrate. None of those facts alone selects your live setting.
For example, suppose a 1080p30 MP4 has a stored video bitrate of 6 Mbps. If an encoder sends it to YouTube as H.264 at 14 Mbps CBR, YouTube receives a 14 Mbps video output, plus audio. If you instead configure the encoder for AV1 at 10 Mbps, the incoming video target is different again. The source file’s 6 Mbps value has not changed the live-ingestion recommendation.
The reverse is also true. A source file with a 20 Mbps stored bitrate does not give you permission to send a 20 Mbps live feed. You still select the outgoing resolution, frame rate and codec, then match the live table. The encoder may need to decode and re-encode the source while it plays.
This distinction matters when you use a playlist or loop. Check the source files for mismatched dimensions, frame rates, audio tracks, black frames and damaged sections, but do not use their stored bitrate as the sole basis for your YouTube Live setting. A file can play correctly from beginning to end while the live output is unstable because the upload connection is insufficient.
YouTube’s separate upload recommendations belong to a different workflow. Uploading an MP4 for on-demand playback is not the same as sending an encoder feed to Live Control Room. For the same reason, do not use an upload table as a substitute for the live-ingestion table above.
If your channel uses a playlist of bhajans or recorded programmes, first verify the content and then verify the live conversion. The guide on creating a YouTube radio-style live stream with a video playlist is useful for the playlist side, while the bitrate decision still comes from the outgoing live feed.
Set CBR, the keyframe interval and RTMPS
Configure constant bitrate encoding, or CBR, for the live output. CBR aims to keep the outgoing video rate predictable instead of allowing large swings as the picture becomes more or less complex. Predictability helps you compare the feed with your available upload capacity and makes troubleshooting clearer.
Set the keyframe interval to two seconds. YouTube’s guidance recommends a keyframe every two seconds and says not to exceed four seconds. A keyframe is a complete reference image from which later frames can be decoded. Regular intervals help the platform process the feed and make it easier for viewers to join at a usable point.
Use RTMPS where your encoder supports it. YouTube lists RTMP and RTMPS for ingestion but recommends RTMPS. In YouTube Studio, prepare the live stream, copy the stream URL and enter it with the stream key in your encoder. Treat the key like a password: do not publish it in screenshots, descriptions or support requests.
The YouTube streaming tips page covers the relationship between stream bitrate and upload bandwidth. YouTube’s live streaming settings guidance also covers testing, previewing and stream health.
Choose the correct colour and dynamic-range settings for the content. For standard dynamic range, YouTube recommends Rec. 709 and 8-bit depth. YouTube identifies H.265 over RTMP or RTMPS for HDR and says AV1 is not supported for HDR. If the source is ordinary SDR, do not select HDR merely because the encoder offers it.
Before starting a public event, open the preview in Live Control Room. Check that the picture is present, audio is moving at a sensible level and the intended title and visibility are correct. A stream key copied into the wrong field can look like a bitrate problem when the real issue is connection or configuration.
Check sustained upload capacity and headroom
A speed test is only a snapshot. For a 1080p30 H.264 stream at the recommended 14 Mbps video rate, the connection must carry that video output, the audio stream and network overhead. It must also retain about 20% of upload capacity beyond the total streaming bitrate, as recommended by YouTube Help.
Do not test only the download result. Download capacity tells you how quickly data can arrive at your connection; it does not establish how much data can leave it continuously. Run the upload test on the same connection, at a similar time of day and with other household or business traffic present if that traffic will continue during the broadcast.
A simple way to plan is to treat the selected video bitrate as the starting point, then add audio and leave the headroom. If your connection barely reaches the video target, it is not a comfortable operating point. A cloud backup, security camera, video call or another person uploading files can consume the remaining capacity without changing your encoder settings.
Wi-Fi adds another variable. A computer may show a good local connection to the router while the router’s uplink is congested or unstable. For a long channel, wired networking is preferable where practical. If you must use Wi-Fi, test from the actual streaming computer and leave more margin rather than assuming a short speed test represents an overnight broadcast.
Your connection also needs consistency. Brief packet loss can cause dropped frames or a temporary reduction in stream health even when an average speed test looks adequate. This is why the target should be treated as part of a test-and-monitor process, not as a guarantee that the broadcast will remain healthy.
The OBS settings guide for 24/7 playlist streaming in India may help if OBS is your chosen encoder. The exact setting names vary between software, but the underlying checks are the same: outgoing resolution, frame rate, codec, CBR, keyframe interval and a connection that can carry the result.
Lower output settings and monitor if needed
If YouTube reports dropped frames, an unstable connection or an encoder that cannot keep up, change one meaningful variable at a time. First confirm that the problem is not a saturated upload connection, an overloaded computer, a faulty cable or a source file that stops during playback. Then reduce the outgoing demand.
You can lower the frame rate from 60 to 30 fps when the content does not need smooth motion. This reduces the recommended live bitrate and may be a better fit for devotional artwork, lecture slides, a radio-style visualiser or a static local information board. For sports, fast traffic footage or rapid screen movement, 60 fps may still be worthwhile if the connection can sustain it.
You can also lower the resolution. Moving from 1080p to 720p reduces the amount of image data that must be encoded and uploaded. Viewers on mobile networks may not notice the difference in a simple visual stream, while they will notice repeated buffering or a stream that disappears.
Do not respond to an unstable connection by raising the bitrate. A higher target cannot repair missing upload capacity. Likewise, lowering the file’s stored bitrate before testing the live output may not solve anything if the encoder is configured to send the same live bitrate and the network remains the limiting factor.
Monitor both the encoder and YouTube. In the encoder, watch dropped frames, rendering or encoding delay, CPU or GPU load and whether the playlist continues to the next item. In YouTube Live Control Room, watch stream health and read the messages rather than relying only on the viewer preview.
For an unattended channel, test the exact file or playlist you intend to use. Include the audio, movement, transitions and loop behaviour that will occur during the real broadcast. YouTube recommends testing before starting and monitoring health during the event. A short test can reveal a wrong aspect ratio or missing audio; a longer test is more useful for discovering a gradual connection or performance problem.
If the broadcast stops repeatedly, keep a record of the time, current bitrate, dropped-frame message and what else was using the connection. The troubleshooting guide for an FFmpeg YouTube stream that keeps stopping covers a more detailed diagnostic path. The same evidence is useful when you are using another encoder.
For operators who do not want a computer running throughout the broadcast, StreamNeo removes the need to keep the source machine encoding and connected overnight: upload the video once, provide the YouTube stream key, and the cloud broadcast can be monitored and restarted if it drops. You still need to choose a suitable live output and verify the channel, source and stream health before relying on it.
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
What bitrate should I use for a 1080p YouTube livestream?
For 1080p30, YouTube’s recommended live-ingestion target is 10 Mbps with AV1 or H.265, and 14 Mbps with H.264. For 1080p60, the corresponding recommendations are 12 Mbps and 17 Mbps. Your upload connection still needs to carry the video, audio and overhead with headroom.
Can I stream a prerecorded video on YouTube Live?
Yes. An encoder can play the file and send its output as a live feed. The file’s stored bitrate is not the live requirement; select the live output settings by codec, resolution and frame rate, then test the actual file for audio, image and continuity.
Is CBR better for a prerecorded YouTube stream?
YouTube recommends constant bitrate encoding for live ingestion because it makes the outgoing rate more predictable. Set a two-second keyframe interval and use RTMPS where supported, then check the encoder and YouTube health messages during testing.
Should I lower resolution or bitrate when the stream keeps buffering?
First check sustained upload capacity, competing traffic and dropped frames. If the connection cannot maintain the selected output with headroom, lower the frame rate or resolution and test again; do not assume that the bitrate stored in the source file is the cause.