Start with the row that matches the video you are sending to YouTube, then choose the columns for your codec. The bitrate figures below are YouTube’s live-ingest guidance verified on 3 October 2026, not a newly published 2026 table.
Your practical setting also depends on whether your upload connection can sustain it. Use the recommended value when the connection is reliable, use the minimum only as a constrained starting point, and test with the same movement and audio your real channel will carry.
How to read YouTube’s live-ingest bitrate chart
A live bitrate chart is easy to misread because three different choices determine the row: ingestion resolution, frame rate and video codec. Ingestion means the video your encoder sends to YouTube. It does not mean that every viewer will receive that same resolution. YouTube transcodes a live input into multiple output formats for different devices and connections.
For example, a 1080p stream sent at 60 frames per second belongs on the 1080p at 60 fps row. It does not belong on the 1080p at 30 fps row merely because the picture is still 1080p. A 1080p30 stream encoded with H.264 then uses the H.264 columns for that row.
The figures are in Mbps, or megabits per second. They describe the video bitrate, not the speed of your internet package and not the storage size of your source file. Audio uses a separate bitrate and needs some additional capacity, while network overhead and normal variation mean that an upload connection should not be operated at its absolute ceiling.
YouTube’s official reference is Choose live encoder settings, bitrates, and resolutions. Keep that page open when you configure a new channel, because YouTube can revise its guidance even though the figures used in this article were checked on 3 October 2026.
The word minimum needs particular care. It is not a promise that the resulting picture will look equally good for every kind of content. A static devotional image, a talking head, a local news loop and a fast gaming scene place different demands on the encoder. The recommended column is YouTube’s suggested target; the minimum column is the lower boundary in the table.
Recommended bitrates by resolution and frame rate
Use the following as a lookup table. Each bitrate pair is shown as minimum / recommended. The first pair is for AV1 and H.265, which YouTube groups together in this table. The second pair is for H.264.
| Ingestion resolution and frame rate | AV1 / H.265 minimum | AV1 / H.265 recommended | H.264 minimum | H.264 recommended |
|---|---|---|---|---|
| 2160p (4K) at 60 fps | 10 Mbps | 35 Mbps | 14 Mbps | 50 Mbps |
| 2160p (4K) at 30 fps | 8 Mbps | 30 Mbps | 11 Mbps | 42 Mbps |
| 1440p at 60 fps | 6 Mbps | 24 Mbps | 8 Mbps | 34 Mbps |
| 1440p at 30 fps | 5 Mbps | 15 Mbps | 7 Mbps | 21 Mbps |
| 1080p at 60 fps | 4 Mbps | 12 Mbps | 6 Mbps | 17 Mbps |
| 1080p at 30 fps | 4 Mbps | 10 Mbps | 5 Mbps | 14 Mbps |
| 720p at 60 fps | 2 Mbps | 6 Mbps | 3 Mbps | 8 Mbps |
| 720p at 30 fps | 2 Mbps | 6 Mbps | 3 Mbps | 8 Mbps |
| 480p at 30 fps | 0.3 Mbps | 3 Mbps | 0.4 Mbps | 4 Mbps |
| 360p at 30 fps | 0.3 Mbps | 3 Mbps | 0.4 Mbps | 4 Mbps |
The row describes what leaves your encoder. It is not a promise that YouTube will display a 4K option immediately, or that a viewer on a slow mobile connection will receive 4K. Your responsibility is to send a stable, correctly configured input; YouTube handles the viewer-side versions through its live processing.
Frame rate changes the recommendation even when resolution stays fixed. For H.264, 1080p rises from 14 Mbps recommended at 30 fps to 17 Mbps at 60 fps. At 4K, it rises from 42 Mbps at 30 fps to 50 Mbps at 60 fps. More frames mean more picture information arriving each second, so the chart gives the higher target.
For a calm study room or a dark-screen white-noise channel, 30 fps may be a sensible choice if there is little motion. A channel showing rapid camera movement, sports-like motion or gaming action may have a clearer reason to use 60 fps, provided the encoder and connection can sustain the matching row. You can read through the practical trade-off in how to stream a 24/7 virtual library study room on YouTube.
Compare AV1 and H.265 with H.264 values
Do not read the first two bitrate columns as a general quality recommendation for every codec. They are the AV1 and H.265 pair in YouTube’s table. H.264 has its own minimum and recommended values, and those values are higher throughout the rows shown above.
Suppose your encoder is set to 1080p30. If the video codec is AV1 or H.265, the table shows 4 Mbps minimum and 10 Mbps recommended. If the codec is H.264, the corresponding figures are 5 Mbps minimum and 14 Mbps recommended. The resolution and frame rate did not change, but the correct bitrate columns did.
This matters when software changes codec automatically. A preset may say 1080p30 while using a different codec from the one you expected. Check the actual video encoder name in the output settings rather than relying on a profile name alone. Then use the matching pair in the table.
YouTube lists RTMP and RTMPS as streaming protocols and names H.264, H.265, and AV1 as video codecs in its encoder guidance. It recommends RTMPS. For the current protocol and encoder requirements, refer to YouTube’s live streaming API and encoder documentation, then confirm that your particular encoder offers the codec you intend to use.
There is no need to force AV1 or H.265 simply because their table is lower. Codec availability, hardware support, encoder stability and the receiving workflow all matter. H.264 can be the more practical choice when it is the codec your software supports reliably. The right column is the one matching the stream that is actually being produced, not the one that gives the smallest number.
For HDR workflows, YouTube’s guidance recommends H.265 over RTMP or RTMPS and does not support AV1 for HDR. That is a separate colour and bit-depth decision from the ordinary SDR chart. If your 24/7 channel is a devotional loop, lofi station or local notice board, confirm whether you are really producing HDR before adding that complexity.
Minimum versus recommended settings
The minimum and recommended figures answer different questions. The minimum asks how low the listed live-ingest bitrate can go for that resolution, frame rate and codec. The recommended value is the target YouTube suggests for that combination.
If your measured upload is comfortably reliable at the recommended video bitrate, start there. If it cannot sustain that setting without repeated congestion, dropping the bitrate alone may not solve the underlying problem. You may need to reduce frame rate or resolution and select the corresponding row instead.
For example, a reliable connection that cannot carry the H.264 1080p60 recommended figure should not be treated as a reason to choose the 1080p30 row while continuing to send 60 fps. Change the encoder output to 1080p30, then use the 1080p30 H.264 value. The settings sent to YouTube and the row consulted must agree.
Do not combine values across columns. H.264 minimum is not interchangeable with AV1 recommended, and 30 fps is not interchangeable with 60 fps. A setting such as 1080p60 at 10 Mbps may be a deliberate test, but it is not the H.264 recommended value from the chart.
There is also a difference between a short successful test and an overnight stream. A connection may briefly reach the required rate and then slow, queue traffic or lose packets later. For an always-on channel, a modest, correctly matched output that remains stable is more useful than a high setting that fails after the evening traffic begins.
If frames are being lost on a computer-based setup, use how to fix dropped frames in an always-on YouTube gaming stream to separate encoder overload, network drops and problems at YouTube. Those causes look similar in a dashboard but need different fixes.
Match the codec, resolution and frame rate in the encoder
Set the encoder in this order: choose the output resolution, choose the frame rate, choose the codec, and then choose the bitrate pair that matches all three. This prevents a common error where someone selects a bitrate first and leaves the output profile unchanged.
For ordinary SDR video, YouTube’s guidance also recommends progressive scan and square pixel aspect ratio. It recommends constant bitrate encoding, usually shown as CBR in encoder software, rather than a mode that varies widely with scene complexity. The guide recommends a 2-second keyframe interval and says not to exceed 4 seconds.
Keyframes are complete reference pictures that help the platform process the stream and recover from changes. A 2-second interval means the encoder inserts them at a regular cadence. If your software offers a keyframe setting in seconds, enter 2 rather than leaving an unpredictable automatic value.
YouTube’s encoder guidance also lists two B-frames, one reference frame and CABAC among its recommended video settings. Names and locations vary between OBS, hardware encoders and other tools, so do not assume that a similar-looking preset has chosen the same values. Where a control is unavailable, keep the bitrate, frame rate, codec and keyframe settings correct first, then consult the encoder’s documentation.
For SDR, the guidance lists Rec. 709. For audio, it lists AAC or MP3, with 128 Kbps for stereo and 384 Kbps for 5.1 surround sound. It lists a 44.1 kHz stereo sample rate and 48 kHz for 5.1. Most devotional, study, ambience and news-loop channels will use stereo, but the audio choice should still be deliberate.
A pre-recorded file needs a clean playback path as well as a correct encoder. If you are using OBS, how to loop a video in OBS for YouTube Live covers the source and loop side; this chart covers the stream that OBS sends after the source has been decoded and encoded.
Check upload capacity and test stream health
Run an upload speed test from the same location and on the same connection that will carry the broadcast. Test at the time you expect to run the channel if possible. A result from a phone on another network does not tell you what the streaming computer can sustain.
Compare the available upload capacity with the video bitrate, audio bitrate and ordinary network overhead. Do not treat the headline speed from an internet plan as a guaranteed bitrate for one continuous stream. Other users, Wi-Fi interference, background backups and a busy router can all reduce the capacity available to the encoder.
YouTube advises testing before starting the live stream and says the test should include audio and movement similar to the planned programme. A still image can hide problems that appear when a scrolling news panel, a moving devotional background or a busy game scene creates more work for the encoder.
During the test, watch the encoder statistics and YouTube’s stream health messages. Look for dropped frames, rising delay, unstable bitrate and audio interruptions. Keep the test long enough to expose a connection that works briefly but does not remain steady. YouTube’s official live streaming troubleshooting guidance is the right place to check current messages and settings rather than relying on an old screenshot.
If the encoder reports frames dropped because of network conditions, investigate the connection path. If it reports skipped or lagged frames because of rendering or encoding, investigate the computer or encoder workload. A higher bitrate will not repair a machine that cannot encode the chosen resolution and frame rate in time.
For a channel intended to run overnight, write down the exact working combination: codec, resolution, frame rate, bitrate, keyframe interval, audio mode and connection used during the test. That record makes it easier to identify what changed if the next broadcast stops. How to make an FFmpeg YouTube stream recover from network errors is relevant when your setup uses FFmpeg and needs a recovery plan as well as a bitrate choice.
Live ingest versus upload encoding
Do not use YouTube’s upload-encoding recommendations to fill in a live-stream bitrate chart. Uploading a finished file and sending a continuous live input are different workflows, with different timing and processing requirements.
This article uses the live-ingest table because the question is what your encoder should send during a broadcast. The relevant inputs are ingestion resolution, ingestion frame rate and ingestion codec. An upload guide may describe a file that YouTube receives in full before processing; that does not make its bitrate figures correct for an ongoing live connection.
The distinction matters for pre-recorded 24/7 channels. A source video may already have a bitrate and resolution, but your playback system still has to produce a live output stream. If that output is re-encoded, choose the live row for the resulting stream. If it is passed through, check what the streaming application is actually sending rather than assuming the source file’s properties.
It also matters when you change a source. Replacing a 720p30 ambience loop with a 1080p60 version changes the row even if the YouTube event and channel remain the same. Replacing H.264 with H.265 changes the columns. Keep a small configuration note beside the channel so that a source change does not silently leave the encoder on an old bitrate.
For a pre-recorded broadcast, how to stream a pre-recorded video as a YouTube Live stream explains the wider workflow. Use this chart for the live input settings within that workflow.
A practical choice for an always-on channel
Start with the output you can support consistently, not the largest resolution your source file happens to contain. A study channel with mostly static pages may have little benefit from 4K if the connection and encoder are less dependable at that setting. A local news loop may need enough clarity for text, while a devotional stream may prioritise uninterrupted audio and a stable image.
Choose one complete row and codec combination, then test it without changing several variables at once. If the test fails, reduce one meaningful demand: move from 60 fps to 30 fps, reduce the resolution, or choose a codec your encoder handles more reliably. Recalculate from the new row rather than applying a proportional guess.
The same discipline helps when the stream must survive a night. Confirm that the source loops correctly, the audio does not drift, the encoder remains active, and the connection does not depend on a laptop that will sleep or install updates. A cloud-based workflow can remove the need to keep your own computer running for the broadcast; StreamNeo is designed for the specific case where you upload the video once, provide the YouTube stream key, and leave the channel running without installing streaming software locally.
No bitrate table can guarantee an uninterrupted broadcast. It can give you a correct starting point, but reliability still depends on the complete path from source to encoder to YouTube. Test the actual programme, monitor the live health messages, and keep the final configuration recorded.
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 the recommended bitrate the speed my internet plan must advertise?
No. The table gives the video bitrate sent to YouTube, while your connection also carries audio, protocol overhead and other traffic. Test the real upload path and leave room for normal variation rather than choosing a plan based only on its headline speed.
Should I use the H.264 row if my source video is H.264?
Use the row for the codec your live encoder sends, not simply the codec of the source file. If the source is decoded and re-encoded as H.265 or AV1, use that codec’s columns; if the live output remains H.264, use the H.264 columns.
Is 60 fps always better than 30 fps?
No. It can make motion smoother, but it also changes the bitrate target and increases the work for the encoder and connection. Choose 60 fps when the programme benefits from it and the matching row remains reliable.
What should I test before leaving a channel running overnight?
Test with representative audio and movement, then watch the encoder and YouTube stream health for dropped frames, interruptions and changing bitrate. Also confirm the loop, power settings, connection and recovery behaviour, because a correct bitrate alone does not test the whole 24/7 setup.