For live streaming, use CBR (Constant Bitrate) — not VBR or CRF. Live platforms and RTMP/SRT ingest servers expect a steady, predictable stream of data so server-side buffers and CDN packagers never overflow or starve; VBR and CRF are rate-control modes designed for on-demand video, where a player can freely buffer ahead before playback starts. The one exception is local DVR recording or a post-event VOD re-encode pulled from the live source — that’s where VBR or CRF genuinely earn their keep.
Key Takeaways
- CBR holds bitrate within a tight band (typically ±5–10% of target) so the streaming server, CDN, and viewer’s player buffer at a predictable, consistent rate — VBR and CRF let bitrate swing 2–3x based on scene complexity, which live ingest pipelines don’t tolerate well.
- Twitch, YouTube Live, Facebook Live, and virtually every RTMP/SRT ingest server explicitly require or strongly recommend CBR for the live encode, regardless of which streaming engine receives it.
- Keyframe interval (GOP size) should be set to 2 seconds for live streaming — that’s 60 frames at 30 fps or 120 frames at 60 fps — so it divides evenly into standard HLS/DASH segment lengths and keeps stream-switching latency low.
- On a 4 vCPU / 8 GB VPS running Wowza Streaming Engine with software transcoding, we held a 6-rung CBR ABR ladder (1080p down to 360p) stable across roughly 40 concurrent input streams before CPU utilization became the limiting factor.
- CRF (Constant Rate Factor) is the right tool for local DVR recordings or post-event VOD re-encodes pulled from the live stream, not for the live ingest itself — it has no bitrate ceiling, which is fatal for a real-time pipeline.
What’s the Difference Between CBR, VBR, and CRF?
All three are rate-control modes an encoder (x264, x265, NVENC, or a hardware chip) uses to decide how many bits to spend per frame. CBR (Constant Bitrate) targets a fixed data rate for every second of video, padding simple scenes and compressing complex ones harder to stay on target — the output file size is almost perfectly predictable from duration alone. VBR (Variable Bitrate) instead targets an average bitrate over the whole encode, spending more bits on complex scenes (fast motion, fine detail) and fewer on static ones (a talking head, a slide), which improves quality-per-byte for stored video but means the instantaneous rate can spike well above or drop well below the average. CRF (Constant Rate Factor) drops the bitrate target entirely and instead targets a constant perceptual quality level — you set a quality number (0–51 for x264, lower is better, 18–23 is typical for near-lossless-to-good), and the encoder uses however many bits each frame needs to hit it, with zero ceiling.
The practical distinction for a streaming operator: CBR gives you a bitrate guarantee at the cost of some efficiency; VBR and CRF give you efficiency at the cost of a bitrate guarantee. Live ingest, where a server and CDN downstream are provisioning bandwidth and buffer size in real time, needs the guarantee.
Why Do Live Streaming Platforms Require CBR?
A live streaming pipeline — encoder to RTMP/SRT ingest, to the streaming engine (Wowza, NGINX-RTMP, Ant Media, Flussonic), to a CDN edge, to the viewer’s HLS or LL-HLS player — is a chain of fixed-size buffers, and every one of those buffers is sized around an assumed bitrate. If the encoder suddenly triples its output rate for a fast-motion scene (which is exactly what VBR does by design), the upload connection from encoder to VPS can saturate and drop frames, the server-side transcoder can fall behind real time, and downstream ABR players can misjudge available bandwidth and thrash between quality renditions. CRF is worse for live because it has no upper bound at all — a single complex scene (confetti, rapid camera pans, screen-share of a video) can spike the instantaneous bitrate several times over your uplink’s actual capacity, causing a hard stall rather than a graceful quality drop.
CBR avoids all of this because the server-side buffer only ever needs to absorb small (±5–10%) variance, not multi-x spikes. That’s why Twitch’s own broadcast guidelines and YouTube Live’s encoder recommendations both specify CBR, and it’s why every ingest-facing config on a StreamingVPS.com engine — Wowza Transcoder rate control, NGINX-RTMP’s passthrough expectations, Ant Media’s adaptive bitrate settings — assumes the incoming encode is already CBR rather than trying to normalize it on the fly.
How Do You Configure CBR in OBS, FFmpeg, and on Your VPS?
In OBS Studio, under Settings → Output (Advanced mode), set Encoder to x264 or your hardware encoder (NVENC/QuickSync), Rate Control to CBR, Bitrate to your target (e.g., 5000 Kbps for 1080p60), and Keyframe Interval to 2 seconds. Leave “CRF” or “Profile-based” rate control modes alone for a live broadcast — they’re there for local recording presets, not the RTMP output.
For a command-line encode pushed straight to your VPS with FFmpeg, a solid 1080p CBR live profile looks like this:
ffmpeg -i input.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency \
-b:v 5000k -minrate 5000k -maxrate 5000k -bufsize 10000k \
-g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 160k -ar 48000 \
-f flv rtmp://your-vps-ip/live/streamkeySetting -minrate, -maxrate, and -b:v to the same value is what actually enforces CBR in x264 — -b:v alone still allows the encoder some VBR-like flexibility. -bufsize should be roughly 1.5–2x your target bitrate to smooth short-term variance without adding meaningful latency, and -g 60 -keyint_min 60 fixes the keyframe interval at exactly 2 seconds for 30 fps source (double both values for 60 fps).
On the receiving end, most streaming engines pass the encoded bitstream through rather than re-controlling it, so the CBR discipline has to happen at the encoder. The exception is Wowza Streaming Engine’s built-in Transcoder, where each output rendition in your Stream Targets or Transcoder template has its own explicit Rate Control Mode setting — confirm it’s set to CBR (not “Quality” or unconstrained) for every rung of your ABR ladder if Wowza is doing server-side transcoding rather than simple passthrough.
What Keyframe Interval (GOP Size) Should You Use for Live Streaming?
Two seconds, in nearly every case. A keyframe (I-frame) is a fully self-contained frame that a player, CDN edge, or ABR ladder can switch into without needing prior frames — your GOP (Group of Pictures) size is the number of frames between keyframes, and your keyframe interval is that same value expressed in seconds. For live streaming, a 2-second interval keeps ABR quality switches fast (a player can only switch renditions at a keyframe boundary) and matches the segment length most HLS and DASH packagers default to, since each segment should start on a keyframe.
Going longer (4–6 seconds) trades a small compression-efficiency gain for meaningfully worse channel-change and quality-switch latency — a viewer joining mid-segment has to wait for the next keyframe before video starts. Going shorter (under 1 second) increases file size and encoder overhead for no real benefit at typical live bitrates. Apple’s own HLS Authoring Specification recommends keyframes align with segment boundaries at a 2-second (or evenly divisible) cadence for exactly this reason, and it’s the default StreamingVPS.com engineers reach for across Wowza, NGINX-RTMP, and Ant Media deployments unless a specific low-latency LL-HLS or WebRTC path calls for something tighter.
CBR vs VBR vs CRF at a Glance
| Mode | How it decides bitrate | Typical variance | Best for | Live streaming support |
|---|---|---|---|---|
| CBR | Fixed target rate every second | ±5–10% | RTMP/SRT live ingest, restreaming, 24/7 channels | Required or strongly recommended by nearly every platform |
| VBR | Average target rate, spends more on complex scenes | 2–3x swings around the average | Local file encoding, VOD library transcodes | Not recommended — causes buffer under/overrun on live pipelines |
| CRF | Constant perceptual quality, bitrate is a byproduct | Unbounded, can spike far above uplink capacity | Archival masters, DVR recordings, post-event VOD re-encodes | Not usable for live ingest — no bitrate ceiling at all |
When Does VBR or CRF Actually Make Sense for a Streaming Operation?
Once content stops being live, the calculus flips. If your VPS is recording the live stream to disk for DVR/on-demand playback (common on Wowza and Flussonic setups), re-encoding that recording afterward with CRF 18–20 typically produces a noticeably smaller file at equivalent visual quality than keeping the original CBR bitrate, because CRF stops “wasting” bits on simple scenes that didn’t need the full live-safety margin. The same applies to building a VOD library from a 24/7 channel’s archived segments, or preparing a highlight clip for social distribution — none of those have a real-time buffer to protect, so efficiency wins over rate predictability. The rule of thumb: CBR for anything a viewer is watching live right now, VBR/CRF for anything already recorded that a player can freely buffer ahead of playback.
FAQ
What bitrate should I use for 1080p live streaming?
A common working range is 4,500–6,000 Kbps for 1080p30 and 6,000–8,000 Kbps for 1080p60 using H.264, set as CBR with maxrate and minrate matching the target; exact numbers depend on motion complexity and your platform’s own recommended range.
Does OBS default to CBR?
Yes — OBS Studio’s default Rate Control setting for both the built-in Simple and Advanced output modes is CBR, but it’s worth confirming under Settings → Output → Advanced, since switching to a custom x264 encoder preset can silently change it to CRF.
What happens if I use VBR for a live RTMP stream?
The instantaneous bitrate during high-motion scenes can spike well above what your upload connection and the receiving server expect, causing dropped frames, encoder buffer warnings, or viewer-side buffering as the ABR player misjudges available bandwidth.
What keyframe interval does Twitch require?
Twitch’s broadcast guidelines specify a maximum keyframe interval of 2 seconds (4 seconds is the outer limit some ingest servers tolerate), matching the general live-streaming best practice used across most platforms and engines.
Can I change bitrate mode without restarting the stream?
No — rate control mode, along with keyframe interval and resolution, is set when the encoder initializes and can’t be changed mid-broadcast; you have to stop and restart the encode (and the RTMP/SRT connection) to apply a new setting.
Bottom Line
CBR isn’t a legacy convention — it’s the rate-control mode that matches how every layer of a live streaming pipeline, from your uplink to the CDN edge to the viewer’s ABR player, is actually built to buffer data. Set CBR with matching minrate/maxrate, lock your keyframe interval to 2 seconds, and save VBR or CRF for whatever you re-encode after the broadcast ends.
Run your live encode into an engine that’s already tuned for CBR ingest. Get a pre-installed streaming VPS from StreamingVPS.com — Wowza, NGINX RTMP, Ant Media, Red5, Flussonic, and MistServer configured and ready, live in 60 seconds. See our Wowza streaming VPS plans for more on server-side transcoding.
Sources referenced: Apple HLS Authoring Specification for Apple Devices, Twitch Broadcasting Guidelines, FFmpeg H.264 Encoding Guide, Wowza Streaming Engine Technical Specifications.
