Every encoding tutorial throws around "bitrate" like everyone was born knowing what it means, then argues about CBR vs VBR like it's a religious matter. The concepts are actually simple — and understanding them is the difference between videos that look right at the size you expected, and videos that disappoint in both directions.

Here is bitrate without the jargon, and how to choose between CBR and VBR.

What bitrate actually is

Bitrate is the data budget: how many bits per second the encoder may spend describing your video. Measured in kilobits (Kbps) or megabits (Mbps) per second.

A higher bitrate means more data per frame, which allows more detail, especially in motion and gradients. A lower bitrate means the encoder must make each bit work harder, throwing away more information.

The key insight: **bitrate does not set quality directly.** It sets a ceiling. The content, the codec, and the resolution determine how much bitrate you need to reach a given quality level. A static talking-head video at 5 Mbps looks perfect; a sports clip at 5 Mbps shows blocking. Same budget, different demands.

CBR (Constant Bitrate)

The encoder spends the same number of bits every second, regardless of what's happening on screen.

When CBR wins

**Live streaming.** Twitch, YouTube Live, and most RTMP servers expect a steady bitrate. A constant flow is easier for the network and the server to handle.

**Fixed-bandwidth systems.** Broadcasting, satellite, and some hardware players require exact, predictable data rates.

CBR's weakness

It wastes bits on easy scenes (a static shot doesn't need the full budget) and starves hard scenes (fast action gets the same allocation as a still frame). The result: big files with suboptimal quality at moments that matter.

VBR (Variable Bitrate)

The encoder analyzes the content and spends bits dynamically: more on complex scenes, less on simple ones.

When VBR wins

**On-demand video.** Anything you encode for playback later — uploads, archives, downloads — benefits from VBR. Better quality at the same average bitrate, or the same quality at a smaller size.

**Storage-constrained delivery.** VBR typically shaves 20-40% off file size versus CBR at equivalent visual quality.

VBR's weakness

Unpredictable peak bitrates can exceed network or player capabilities momentarily. Some hardware decoders and older systems struggle with bitrate spikes.

The VBR modes you'll meet

Single-pass VBR

The encoder makes decisions on the fly. Fast, reasonably good, slightly less efficient than two-pass.

Two-pass VBR

The first pass analyzes the entire video; the second pass encodes with that knowledge, distributing the budget optimally across the whole timeline. Slower, but the most quality per bit. The standard for archival encodes.

Constrained VBR (CVBR)

VBR with a ceiling. The encoder varies the bitrate but never exceeds a maximum. The compromise for streaming-adjacent use cases.

Quality-based encoding (CRF)

Neither CBR nor VBR in the traditional sense — you set a quality target (the CRF number), and the encoder uses whatever bitrate each section needs to achieve it. File size is whatever it turns out to be. This is the modern default for single encodes: set CRF, let the encoder be smart. It is, effectively, the most intelligent form of VBR.

The practical decision tree

**Livestreaming?** CBR. Steady and predictable.

**Uploading to a video platform?** Upload the highest-quality master you have. The platform's encoder handles the ladder. If you're encoding the master: CRF-based (quality-target) encoding.

**Archiving or space-constrained?** Two-pass VBR or CRF. Maximum quality per byte.

**Hardware playback of uncertain vintage?** Constrained VBR with a conservative peak, or CBR if you want zero risk.

The takeaway

CBR for live and fixed-pipeline systems. VBR (or CRF) for everything you encode for playback. The argument between them isn't about quality — it's about predictability. When you need predictable, use CBR. When you need efficient, use VBR. And when you just want the best result with a single command, use CRF and let the encoder's intelligence do the thinking.