If your OBS stream appears stuck at 30 fps, first check the output rate OBS is actually set to send, then verify that the source and your computer can sustain the higher rate. YouTube supports incoming streams up to 60 fps, but that is a platform ceiling, not a promise that every setup will deliver 60 reliably.
Work through the checks in order: OBS output, source capability, rendering and encoding performance, then YouTube’s detected input. Only after confirming what YouTube received should you use the viewer playback menu to diagnose the problem.
1. Check OBS’s requested output rate
Open Settings > Video in OBS and look at Common FPS Value. This is the requested output frame rate; it does not automatically follow the game, camera or clip playing in your scene. OBS’s overview guide says this value should match the desired output FPS, giving 30 and 60 as examples.
If you want to test a 60 fps stream, set Common FPS Value deliberately to 60, apply the change and run a private or otherwise low-risk test. Do not infer the output rate from a game’s frame counter, a camera’s product description or a source’s properties alone. OBS is the final point in that chain where you choose the stream’s requested output cadence.
Also note Output (Scaled) Resolution in the Video settings. The canvas resolution and the scaled output resolution are distinct. Your canvas is the space in which you arrange sources; the scaled output is the resolution OBS sends for the stream. A source can be captured at one size while OBS sends another, and changing one field does not necessarily change the other.
Before touching encoder settings, write down both the intended output FPS and output resolution. If Common FPS Value is set to 30, a faster encoder preset or higher bitrate will not make OBS send 60 frames per second. Correct the requested rate first, then test the complete scene rather than relying on a menu change as proof that the change survived the broadcast path.
For a test that will not disturb a public channel, follow a private workflow such as this guide to testing a YouTube Live loop privately. Keep the scene, motion and source types representative: a static desktop may render easily while a busy game capture, animated overlays or moving background pushes the system harder.
2. Verify the source can supply the target rate
Once OBS requests the rate you want, check whether each important source can produce it. A camera may have a frame-rate setting, a capture device may expose multiple modes, and a game-capture path can behave differently from a media file or screen capture. The relevant limit depends on the particular source and capture chain, so do not assume that a device supports the chosen rate merely because its packaging or software mentions a higher maximum in some mode.
Inspect the source’s own settings and the mode currently selected in OBS. For a camera, check the selected video mode and any application settings controlling frame rate. For a capture card or console feed, check the output format at the console and the mode received by the capture source. For a file or loop, inspect how it is being played into the scene. A 30 fps source can be sent in a 60 fps OBS output, but repeating frames does not create new motion detail.
This distinction matters when only one part of the scene seems smooth or choppy. If a webcam looks like 30 fps but gameplay looks smoother, the camera source may be the limit while OBS’s stream output is higher. If every moving element appears to update at the same lower cadence, check the overall output and system load too. Visual inspection helps narrow the problem, but it does not replace checking OBS and YouTube’s reported values.
Avoid buying a camera or capture card before identifying the constrained link. If your current source cannot supply the target mode, a source change might be relevant; if it already can, the limitation may instead be a setting, cable path, driver, or computer workload. The research available for this general problem does not establish a universal device recommendation, so verify the exact mode supported by your equipment and operating system.
For a continuous music stream, the source may be a playlist, audio visualisation or a video loop rather than a camera. Moving album artwork or a now-playing overlay can add visual work even when the music itself is static. This guide to showing track information on a 24/7 music stream is relevant if you are checking whether added scene elements are part of the capture chain.
3. Check rendering and encoding performance
OBS must render the scene and encode each output frame. Both jobs consume system resources, and increasing resolution or frame rate raises the work involved. A target of 60 fps gives the system less time to render and encode each frame than 30 fps. If the machine cannot keep pace, OBS can miss frames even though the requested value remains 60.
During a representative test, look at OBS’s performance indicators and the statistics window. Separate rendering lag from encoding lag where OBS reports them: rendering trouble points towards scene composition or GPU capacity, while encoding trouble points towards the selected encoder and its ability to process the frames. Also check for network drops, but do not mistake a network warning for evidence that OBS’s Common FPS Value is wrong. Different bottlenecks call for different changes.
The OBS encoding performance troubleshooting guide identifies GPU overload or a GPU bottleneck as common reasons OBS cannot keep up. Close applications using substantial graphics resources, reduce unnecessary browser sources or animated elements, and test a simpler scene. Then add sources back one at a time. This gives you a useful comparison without assuming that a new graphics card is the answer.
Try the same scene and motion at the intended output resolution and rate. A desktop scene with a still background is not a fair test for a fast game or several moving overlays. If performance fails only when you reach a demanding scene, reduce the workload or choose a lower output target. OBS’s guidance is to try 30 fps if 60 cannot be sustained; a stable 30 fps stream is preferable to a higher setting that continually drops frames.
A hardware encoder may help if encoding is the diagnosed constraint and your hardware, operating system, drivers and OBS version support the relevant option. It does not remove scene-rendering limits, source limits or other compatibility issues. The OBS hardware encoding notes explain that available options depend on platform support; use them to check compatibility rather than treating hardware encoding as a guaranteed fix.
If your stream includes a long playlist rather than a live game or camera, consider whether the computer needs to stay involved in the broadcast at all. StreamNeo removes the specific burden of leaving your own computer running to keep an uploaded file on air, which is useful when local machine stability is the part that keeps interrupting a continuous file-based stream. It does not change what a particular source can supply or guarantee a 60 fps result.
4. Review resolution and encoder settings
Resolution and frame rate should be considered together. Higher output resolution asks OBS and the encoder to process more image data, while a higher frame rate asks them to process frames more often. When the combination is too demanding, test a lower output resolution, a lower frame rate, or both, then compare OBS performance and YouTube’s received input. Do not change several settings at once if you want to learn which constraint mattered.
For YouTube ingestion over RTMP or RTMPS, YouTube’s live encoder settings document H.264, H.265/HEVC and AV1 as supported video codecs and list input frame rates up to 60 fps. The same guidance recommends constant bitrate (CBR) and a two-second keyframe interval, with the interval not exceeding four seconds. These settings help with compatibility and delivery; they do not select the frame rate OBS sends.
YouTube’s recommended H.264 live-ingestion bitrate varies by resolution and frame rate. As listed on YouTube’s site in September 2026, its recommendations include 17 Mbps for 1080p at 60 fps, 14 Mbps for 1080p at 30 fps, and 8 Mbps for 720p at either 30 or 60 fps. These are codec-specific recommendations, not guaranteed minimum connection speeds, and they are not a switch that converts a 30 fps output into 60 fps. Use the row for your chosen input format and codec rather than borrowing a value from a different row.
| Output format | YouTube H.264 live-ingestion bitrate recommendation | What to take from it |
|---|---|---|
| 1080p at 30 fps | 14 Mbps | A recommendation for this input format, not a rate control for FPS |
| 1080p at 60 fps | 17 Mbps | Higher than the listed 30 fps recommendation at this resolution |
| 720p at 30 fps | 8 Mbps | Same listed recommendation as 720p at 60 fps |
| 720p at 60 fps | 8 Mbps | Does not mean the computer can encode this format reliably |
The figures are YouTube recommendations, not a reason to raise bitrate blindly. Your upload connection needs to support the chosen stream consistently, with room for ordinary variation; increasing bitrate can make delivery less stable on a constrained connection while leaving Common FPS Value unchanged. If you are separately diagnosing connection capacity for a long-running channel, the upload-speed guide for a continuous prerecorded stream covers that distinct question.
For other encoder details, keep the selected codec and OBS options aligned with what YouTube accepts and what your system supports. YouTube’s guidance also describes progressive scan, square pixels, two B-frames, one reference frame and CABAC among recommended advanced settings, and lists Rec. 709 with 8-bit depth for SDR. You do not need to change all of these to investigate a 30 fps symptom; prioritise Common FPS Value, the source mode and OBS’s performance indicators first.
5. Confirm what YouTube received
After checking OBS output, source and performance, confirm the incoming stream in YouTube’s Live Control Room. YouTube advises testing ahead of an event and monitoring stream health and messages there. Its live stream settings help describes stream controls and the default detection of incoming resolution and frame rate. The detected properties give you evidence about the input, rather than what a viewer’s playback menu happens to offer.
Compare the detected resolution and frame rate with your OBS output settings during a test. If OBS is set to 30 and YouTube reports 30, the request and received input agree. If OBS is set to 60 but YouTube detects 30, return to OBS statistics and inspect the source mode and system performance. If YouTube detects 60, then the incoming stream reached the target rate; a viewer’s seeing a 30 fps option requires a separate interpretation.
Check stream health messages alongside those properties. A dashboard warning can indicate a delivery issue even if OBS requests 60, and a clean-looking preview does not by itself establish the exact input rate. Test with typical audio and motion and allow the stream to run long enough to observe whether the result stays consistent. For a public event, do this ahead of time rather than making your first diagnosis while viewers are waiting.
YouTube can automatically detect incoming resolution and frame rate. A custom stream key can allow manual selection of stream resolution, so if you have configured a custom key, review its settings as part of the check. Do not assume that a playback option or an old configuration describes the current incoming signal; use the current stream’s detected properties and health information.
6. Interpret viewer playback carefully
YouTube transcodes live streams into multiple playback formats. That means the frame rate available to a viewer can differ from the frame rate OBS sent, and a viewer selecting 30 fps is not, by itself, proof that OBS delivered only 30. The OBS transcoding notes explain why the incoming stream and a viewer’s rendition are different parts of the path.
Use a simple order of evidence: first the Common FPS Value in OBS, then OBS performance and source capability, then YouTube’s detected input, and only then the viewer’s playback choices. If Live Control Room reports 60 fps but one device offers 30 fps, compare playback on another device or wait for processing and available renditions to settle before changing the encoder. A viewer’s network, device and selected playback quality can affect the rendition they see.
If Live Control Room reports 30 fps while OBS requests 60, treat that as a capture or output-path issue until proven otherwise. Check that the selected OBS profile and scene are the ones actually streaming, that the source can provide the intended cadence, and that rendering and encoding are keeping up. If YouTube reports 60, but playback looks like 30, do not lower the stream just to match one viewer menu without checking another playback path.
The central distinction is between requested, received and played back frame rate. OBS’s setting is requested output; Live Control Room helps establish the incoming stream; the viewer menu shows playback choices after YouTube’s processing. Keeping those three stages separate prevents an unnecessary bitrate change or hardware purchase based on the wrong symptom.
7. Use a controlled test before changing hardware
A short, controlled test is more useful than changing several settings and hoping the stream looks smoother. Record the starting OBS output resolution and Common FPS Value, the source mode, and whether OBS reports rendering or encoding trouble. Make one adjustment, test the same representative motion, and compare the new OBS and Live Control Room information. If you cannot hold the target rate without dropped frames, step back to a stable configuration.
For example, suppose your scene has a 60 fps game capture, animated alerts and a browser overlay, while OBS is set to 60 fps at 1080p. If OBS shows rendering lag, remove or simplify an overlay and test again before changing bitrate. If rendering is healthy but encoding struggles, compare a supported encoder option or reduce output resolution. If the source itself is limited to 30, changing encoder settings cannot recover frames the input never supplied.
If you are running a scheduled or all-day channel, weigh the practical cost of monitoring a local OBS machine against the control it gives you. OBS is appropriate when you need interactive scenes, cameras, live switching or direct access to local sources. A file-based loop has different needs, and moving that workload away from your everyday computer can address the specific risk of leaving it powered on. Neither route removes the need to choose appropriate content, verify YouTube’s current settings and test the final stream.
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
Why is OBS still sending 30 fps when Common FPS Value is set to 60?
The selected source may be limited to 30, or OBS may be unable to render or encode the scene at the requested rate. Check OBS performance during representative motion, then compare the incoming rate shown in Live Control Room. A 60 setting is a request, not proof that every stage is keeping up.
Does raising bitrate make a stream 60 fps?
No. Common FPS Value sets OBS’s requested output rate; bitrate is a separate encoding and delivery setting. Follow YouTube’s recommendation for the selected resolution, frame rate and codec, but do not treat more bitrate as a frame-rate control.
If YouTube supports 60 fps, will my setup be able to stream it?
Not necessarily. YouTube’s stated support up to 60 fps describes the incoming platform limit, not a guarantee for a particular source, computer, encoder configuration or connection. Test your own scene and keep a stable 30 fps output if the system cannot sustain the higher target.
The viewer menu only shows 30 fps. Is OBS the problem?
Not on that evidence alone. YouTube creates multiple playback renditions, so first check what Live Control Room says it received. If the input is 60 fps, investigate the available playback rendition and device rather than assuming OBS sent only 30.