Media Production Tools
Menu

CBR vs VBR: Which Should Creators Use?

Constant and variable bitrate are rate control modes, and encoder documentation defines them precisely. This guide sets out what each mode does, what it means for a size estimate, and when the predictability of CBR is worth its cost.

Published 2026-08-11 · Updated date pending

The short answer

Constant bitrate holds the data rate steady and lets quality move. Variable bitrate holds a quality target and lets the data rate move. Most delivery work wants variable bitrate, because it spends bits where the picture needs them. Live streaming wants constant bitrate, because the receiving end has a fixed pipe to fill and cannot absorb a spike.

Either way, a file size estimate uses the average bitrate. Put your average into the Video Bitrate Calculator and the arithmetic is identical for both modes.

The modes, as encoder documentation defines them

Microsoft’s encoder rate control enumeration is a useful inventory because it names the modes without editorialising. It lists constant bit rate encoding; constrained variable bit rate encoding; unconstrained VBR encoding; quality-based VBR encoding, where “The encoder selects the bit rate to match a specified quality level”; and three further low-delay and global VBR variants introduced as H.264 extensions.

x265’s documentation shows what those look like as encoder settings:

  • --bitrate “Enables single-pass ABR rate control. Specify the target bitrate in kbps.” Average bitrate: aim at a number over the whole encode.
  • --crf is documented as the default: “CRF is the default rate control method; it does not try to reach any particular bitrate target, instead it tries to achieve a given uniform quality and the size of the bitstream is determined by the complexity of the source video.”
  • --qp “Specify base quantization parameter for Constant QP rate control.”
  • --vbv-bufsize and --vbv-maxrate constrain the buffer and the maximum local bitrate. The documentation notes that vbv-maxrate “Will be used only if vbv-bufsize is also non-zero.”
  • --pass “Enable multi-pass rate control mode. Input is encoded multiple times, storing the encoded information of each pass in a stats file from which the consecutive pass tunes the qp of each frame to improve the quality of the output.”

The important consequence of that CRF line: an encoder left on its defaults is not targeting your bitrate at all. If you want a specific number, you have to ask for it.

What CBR actually constrains

True constant bitrate is not a single setting so much as a bitrate target plus a buffer constraint tight enough that the encoder cannot deviate far from it. That is what the VBV parameters do: cap the local bitrate and bound the buffer, so the instantaneous rate stays inside a window a decoder — or a streaming ingest — can handle.

The cost is paid in quality. A fixed budget on a complex scene means fewer bits per detail than that scene wanted; the same fixed budget on a static shot spends bits that had nothing to describe.

The benefit is predictability, in two senses. The file size is known before the encode finishes. And the peak rate is bounded, which is what a live ingest endpoint needs, since it cannot buffer an arbitrary spike.

Two-pass VBR: predictable size without a fixed rate

The middle path is multi-pass. FFmpeg documents it plainly: the -pass option “is used to do two-pass video encoding. The statistics of the video are recorded in the first pass into a log file (see also the option -passlogfile), and in the second pass that log file is used to generate the video at the exact requested bitrate.”

That is the combination most delivery work wants: the average is hit exactly, so the file size is predictable, while the instantaneous rate is still allowed to vary according to what each scene needs. The cost is time — the source is encoded twice.

Worked example: the size arithmetic is the same either way

A ten-minute encode at an average of 12 Mbps of video plus a 128 Kbps audio track:

totalBitrate  = 12 000 000 + 128 000 = 12 128 000 bps
payloadBits   = 12 128 000 x 600     = 7 276 800 000 bits
fileSizeBytes = 7 276 800 000 / 8    =   909 600 000 bytes
              = 909.60 MB

Under CBR the encoder holds close to 12 Mbps throughout. Under two-pass VBR at an average of 12 Mbps it may run at 4 Mbps over a static shot and 25 Mbps over a complex one. Both land on 909.60 MB, because the average is what the arithmetic consumes.

Run it in reverse to confirm: feeding 909,600,000 bytes, 600 seconds and a 128 Kbps audio track into the Video Bitrate Calculator returns 12.000 Mbps.

The failure case is single-pass CRF or quality-targeted VBR, where no average was requested. Then there is no average to type in until the encode has finished, and the estimate is a guess.

Which to choose

  • Uploading to a platform. Two-pass VBR at the platform’s recommended bitrate. You hit the recommendation exactly and still spend bits where they matter.
  • Live streaming. CBR. The ingest endpoint has a fixed capacity, and a bounded peak rate is the point.
  • Archiving or mastering. Quality-targeted, such as CRF, and accept that the size is unknown until it is done. x265’s own documentation says the bitstream size “is determined by the complexity of the source video” in that mode.
  • Delivering to a hard size limit. Two-pass VBR, with the target bitrate computed from the limit. That is exactly what the bitrate calculator produces.

Audio is often handled separately from video. Vimeo, for instance, recommends AAC-LC at 48 kHz and 320 kb/s CBR for the audio track, alongside its video guidance.

What this does not tell you

  • No quality comparison is offered. Nothing here was encoded, viewed or scored. The statements about what each mode does come from encoder documentation.
  • Mode names differ between encoders. “VBR” in one application’s interface may mean single-pass ABR, quality-targeted, or capped VBR. Read your encoder’s documentation, not the label.
  • CBR is rarely exactly constant. It is a target plus a buffer constraint, and behaviour at the boundary is implementation-specific.
  • The calculator models no rate control. It takes an average bitrate and does arithmetic. That is the whole of its claim.

Frequently asked questions

Which gives better quality at the same file size?

At the same average bitrate, variable bitrate can allocate bits where the picture needs them, which is the reason the mode exists. This site publishes no measurement of the difference, because it has made none.

Why is my CRF export a completely different size than I expected?

Because CRF does not target a size. x265’s documentation states that CRF “does not try to reach any particular bitrate target” and that bitstream size “is determined by the complexity of the source video”. Switch to a bitrate-targeting mode if you need a predictable size.

Does CBR make streaming more reliable?

It bounds the peak rate, which is what a fixed-capacity ingest path needs. That is the property live streaming depends on. Whether a given stream is reliable depends on much more than rate control.

Is two-pass worth the extra time?

If you need to hit a bitrate exactly, FFmpeg documents that the second pass generates “the video at the exact requested bitrate”. If you do not need a specific size, a single quality-targeted pass avoids the second encode entirely.

What average bitrate should I put into the calculator?

The one you asked the encoder for. If you used a quality-targeted mode and asked for no bitrate, there is no average to enter until the file exists — at which point you can measure it from the file itself.

Sources