For an H.264 gaming stream from OBS, start with 17 Mbps at 1080p60, 14 Mbps at 1080p30, and 8 Mbps at either 720p60 or 720p30. Set the encoder to CBR and use a 2-second keyframe interval.
These are live-ingestion settings for the broadcast sent to YouTube, not targets for uploading a finished VOD file. Your upload connection must sustain the chosen setting reliably, so test with similar gameplay and audio before relying on it for a long stream.
Recommended OBS bitrate by resolution and frame rate
The correct bitrate depends first on the output resolution and frame rate, then on the codec being sent to YouTube. The table below uses YouTube’s H.264 live-encoder recommendations, which are the relevant starting points for the common OBS gaming setup.
| OBS output | Frame rate | H.264 live bitrate to start with |
|---|---|---|
| 1080p | 60 fps | 17 Mbps |
| 1080p | 30 fps | 14 Mbps |
| 720p | 60 fps | 8 Mbps |
| 720p | 30 fps | 8 Mbps |
| 1440p | 60 fps | 34 Mbps |
| 1440p | 30 fps | 21 Mbps |
| 2160p, 4K | 60 fps | 50 Mbps |
| 2160p, 4K | 30 fps | 42 Mbps |
For most gaming channels, 1080p60 is the first row to consider when fast movement and readable on-screen detail matter. If your connection or computer cannot deliver that combination consistently, 1080p30 is a more sensible fallback than forcing 60 fps and accepting interruptions. A 720p60 stream can also suit gameplay where smooth movement matters more than fine text.
YouTube publishes separate recommendations for AV1 and H.265/HEVC. At 1080p60, for example, its table lists 12 Mbps for AV1 or HEVC, compared with 17 Mbps for H.264. The setting only makes sense if OBS and your selected encoder are actually sending that codec. Do not take a value from one codec’s row and apply it to another.
The H.264 values above come from YouTube’s live encoder settings and bitrate guidance. They are platform recommendations for ingestion, not a guarantee that a particular broadband or mobile connection will carry the stream without drops.
Set CBR and a 2-second keyframe interval
In OBS, choose constant bitrate, usually shown as CBR, for the video encoder. This gives YouTube a predictable stream rather than one whose bitrate rises and falls substantially with the complexity of each scene. A busy game scene can require more data than a static menu, so a steady setting makes it easier to test whether the connection can cope.
Set the keyframe interval to 2 seconds. YouTube’s encoder guidance recommends this interval and says not to exceed 4 seconds. The exact field name can vary with the OBS version and encoder you select, but it is normally found among the encoder’s advanced output options.
A keyframe is a complete reference image from which later frames can be reconstructed. The interval affects how frequently those reference points arrive. It is not a replacement for adequate bitrate, and changing it will not repair an upload connection that is losing packets or running out of capacity.
Use RTMPS where it is available in your YouTube and OBS configuration. YouTube lists RTMPS in its live encoder guidance. Keep the stream key private, and if you believe it has been exposed, replace it in YouTube before starting another broadcast.
The rest of the encoder settings still matter. Select the intended video encoder, confirm that the output frame rate is what you tested, and make sure the audio source is present. Do not change resolution, frame rate and encoder immediately before the real broadcast and assume that an earlier test covers the new combination.
Match output resolution and frame rate
The bitrate row must match the actual video being sent. If OBS is outputting 1080p at 60 fps, use the 1080p60 starting point. If the output is 1080p at 30 fps, use the 1080p30 row. The game may render internally at a different resolution, but the important comparison is OBS’s final stream output.
Resolution describes the number of pixels in each frame. Frame rate describes how many frames are sent each second. Raising either one can increase the amount of visual information that must be encoded and delivered. A fast racing game at 60 fps places a different demand on the stream from a slower strategy game at 30 fps, even when both are set to 1080p.
Check OBS’s output settings rather than relying on the game’s display settings. A game might run at 1440p on your monitor while OBS scales the stream to 1080p. Conversely, OBS might be configured to send 1440p when you thought the stream was still at 1080p. The bitrate recommendation follows the output that YouTube receives.
If small text, a chat panel or a game interface is important, reducing resolution can make those elements harder to read. If movement is the main concern, reducing frame rate may make the stream feel less fluid. There is no universal winner between 1080p30 and 720p60; choose according to what viewers need to see and what your connection can sustain.
Do not confuse the output resolution with the size of your local recording. OBS can record a separate file while streaming, but the live bitrate in this article applies to the stream output. If you keep a local recording for later editing, inspect its recording settings separately.
For a channel built around a long prerecorded loop, the same distinction matters. A pre-recorded video live-stream bitrate setting guide may help you think through the difference between a file and a live broadcast, but the values here still need to follow the live-ingestion row for your chosen output.
Check upload capacity before going live
A 17 Mbps stream needs an upload connection that can carry 17 Mbps of video data repeatedly, not merely a speed-test result that briefly reaches that figure. The connection also has to handle audio, protocol overhead and other activity on the network. Because of that, treating the headline speed-test number as spare capacity can give a false sense of security.
Run the test from the same computer and network you will use for the broadcast. If possible, test at the time of day when the channel normally runs. A wired connection can remove one source of variation, but it does not change the capacity supplied by your internet connection. On Wi-Fi, distance, interference and other users can affect the result.
YouTube recommends running a speed test to check upload bitrate. Its guidance also recommends testing before starting the live stream, with audio and movement similar to what you will use during the broadcast. Follow that advice instead of testing only a static OBS scene.
For example, a 1080p60 gaming test should include ordinary gameplay, camera movement, overlays and the microphone or music mix that will be present in the real stream. Leave it running long enough to expose the problem you are trying to avoid. A short test that happens to complete cleanly cannot demonstrate that an overnight stream will remain stable.
Pause or schedule other uploads, cloud backups and large file transfers during the test. If another person is watching high-resolution video, using a video call or uploading a phone backup, the result may describe the household’s combined traffic rather than the capacity available to OBS.
The useful question is not only “What upload speed do I have?” It is “Can this network carry this particular OBS output without repeated instability?” If the answer is uncertain, start with a lower output row and observe the stream rather than selecting the highest resolution on paper.
A 24/7 channel also has to account for the data sent over time. The monthly bandwidth guide for a 24/7 stream explains why a bitrate that seems manageable for a short gaming session can become a substantial continuous transfer when a channel runs all day and night.
Test and monitor YouTube stream health
Create a private or unlisted test broadcast if you do not want the trial stream to appear publicly. Start OBS with the same scene collection, game, audio sources, output settings and network path that the real channel will use. A test made with a still image is not a meaningful test of a gaming stream.
Once the signal reaches YouTube, watch the stream-health messages in YouTube Studio. Look for warnings about a poor connection, missing data or other delivery problems. Also watch OBS’s statistics window for dropped frames caused by the network, rendering or encoding issues. These indicators describe different parts of the path, so read them together rather than assuming every dropped frame has the same cause.
If YouTube reports that the stream is healthy but OBS shows rendering or encoding strain, the upload connection may not be the main problem. If OBS is encoding normally while dropped frames accumulate because of the network, reducing the video output or resolving the connection issue is more relevant than changing the game’s graphics quality.
Check the stream from a second device as well. A viewer-side buffer does not prove that the encoder is healthy, but it can reveal obvious freezes, missing audio, a black screen or a mismatch between the intended and delivered frame rate. Keep the test content representative and listen for audio clipping or an absent microphone.
YouTube’s official live encoder documentation is the right place to check current guidance because platform requirements and available codec options can change. The stream-health panel is more useful than a generic speed-test score once the broadcast is actually running.
Do not judge the test only by whether the stream starts. A connection can establish a broadcast and still fail later when gameplay becomes busy or another device begins using the network. The purpose of testing is to find those conditions before viewers depend on the channel.
Reduce settings if the connection is unstable
If the stream repeatedly reports delivery problems, do not keep increasing bitrate or changing several unrelated settings at once. First identify whether the issue is network capacity, encoder load or the source itself. Then make one controlled change and test again.
For a common H.264 setup, the practical reduction path is often from 1080p60 at 17 Mbps to 1080p30 at 14 Mbps, or to 720p60 or 720p30 at 8 Mbps. These are not arbitrary lower numbers. Each is the corresponding YouTube recommendation for a different output resolution and frame rate.
Choose between those options based on the content. A competitive game with rapid camera movement may benefit from retaining 60 fps at 720p. A game with menus, subtitles or detailed interfaces may be easier to read at 1080p30. If both the connection and the computer are under pressure, 720p30 is the simpler output to test.
If OBS reports encoding overload rather than network drops, lowering the game’s graphics settings, reducing the output resolution or selecting a less demanding encoder path may help. Your graphics card or processor still has to capture, compose and encode each frame. A faster internet connection will not fix a computer that cannot produce the frames in time.
If the problem appears only when other devices are active, manage the local network before lowering the stream permanently. Stop competing uploads, move the computer to a more reliable connection and check whether the problem returns under normal household use. The aim is to test the circumstances in which the channel will actually operate.
For an always-on channel, a failed overnight stream is also an operational problem. A guide to recovering a YouTube live stream after a dropped connection can help you plan what to check when the broadcast stops, but recovery steps do not remove the need to choose a sustainable bitrate.
If you do not want your own computer running throughout a prerecorded 24/7 broadcast, StreamNeo removes the specific overnight computer and restart burden by taking an uploaded video, YouTube stream key and chosen channel configuration and running the broadcast for you from the cloud. It is YouTube-only, so it does not change the bitrate rules for the live signal or remove the need to check the channel’s health.
Keep live bitrate separate from finished-VOD upload settings
The phrase “VOD stream” can describe two different things. It may mean a live gaming broadcast that YouTube keeps as an archive after the stream ends, or it may mean a finished video file that you upload to YouTube. The bitrate tables for those two workflows are not interchangeable.
The values in the first table are for live ingestion from OBS to YouTube. They describe the encoded signal travelling during the broadcast. They are not instructions to export a finished 1080p video at 17 Mbps, and they do not tell you how large an uploaded file should be.
YouTube’s separate SDR upload guidance lists 8 Mbps for standard frame rates of 24, 25 or 30 fps at 1080p, and 12 Mbps for high frame rates of 48, 50 or 60 fps at 1080p. Those figures belong to the upload-file workflow. Check YouTube’s recommended upload encoding settings when preparing a finished file, rather than copying the live-ingestion number into your export preset.
A live archive is still created from a live broadcast. YouTube says that live streams shorter than 12 hours can be automatically archived, and its archive behaviour is separate from the bitrate selected for ingestion. The archive does not turn the live bitrate table into a VOD upload table.
This distinction matters when you record gameplay locally and also stream it. The live copy may use the H.264 1080p60 starting point of 17 Mbps, while your editing export may use a different file-encoding recommendation. Keep separate presets in OBS or your editor so a change made for one workflow does not silently alter the other.
If your main plan is to upload a completed gaming session rather than broadcast it in real time, you may not need OBS’s live output at all. If your plan is to send a continuous signal to YouTube and let the platform archive it, use the live settings, test them and monitor the broadcast.
A practical setup sequence
Start by writing down the output you actually want: for example, 1080p at 60 fps. Then confirm which codec OBS will send. Select the matching YouTube live bitrate, set CBR, set the keyframe interval to 2 seconds and verify the protocol and stream key before testing.
Next, remove competing network activity and run a representative private or unlisted broadcast. Use real gameplay movement, the intended audio sources and the same overlays that will be active later. Watch both OBS statistics and YouTube’s stream-health messages instead of relying on whether the preview appears.
If the test is stable, repeat it under the conditions closest to the planned schedule. If it is unstable, decide whether the cause is the network or the computer, then lower resolution or frame rate and choose the new row’s recommended bitrate. Do not call a 720p30 test proof that a later 1080p60 stream will work.
Before an important broadcast, check the stream key, audio source, scene, output resolution, frame rate and recording or streaming destination. Keep a written note of the working settings. This makes it easier to restore a known configuration after an OBS update or an experimental change.
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 17 Mbps always correct for a 1080p60 gaming stream?
It is YouTube’s H.264 live-ingestion starting point for 1080p60, not a guarantee for every connection. Your upload capacity, network conditions and encoder performance still need to support it reliably.
Should I use 1080p30 or 720p60 when 1080p60 is unstable?
Choose according to the content and the problem. 1080p30 preserves more resolution, while 720p60 preserves smoother motion, and both should be tested with representative gameplay before the public stream.
Can I use the live bitrate as my finished VOD export bitrate?
No. Live-ingestion recommendations and uploaded-file encoding recommendations are separate. Use YouTube’s upload guidance for a completed file and the live table for the signal sent from OBS during a broadcast.
What should I check when viewers report buffering?
First inspect YouTube’s stream-health messages and OBS statistics, then check whether other devices or uploads are using the connection. If the problem continues, lower the output resolution or frame rate and select the corresponding live bitrate instead of forcing the original setting.