Rate Control Simulator

see how CRF adapts bitrate to complexity while CBR holds a fixed target at the cost of quality variance

Loading interactive simulation...

A CRF number does not travel between encoders 🖖

CRF looks like an absolute quality scale, and within one encoder at one preset it behaves like one. Across encoders it does not. The value is an index into that particular encoder’s internal quantiser decisions, not a measurement of anything, so copying a setting from an x264 command line to an x265 one silently changes what you asked for β€” the rough working equivalence is that x265 needs a number about 5 or 6 higher to look the same, because its default quantiser scaling differs. Presets move the target too, since they change which decisions the encoder is willing to spend time on. The only reliable way to match quality across two encoders is to encode a sample with each and compare.

Set the quality or set the size 🖖

Rate control is really a choice about which knob you fix. With CRF you pick a quality level and let the file size land wherever the footage demands. With CBR you fix the bitrate and let quality rise and fall with the scene. A good rule of thumb: choose CRF for downloads and archives where size can vary, and CBR for live streaming or broadcast where the bandwidth is fixed.

CRF quietly lowers quality on busy scenes 🖖

Despite the name, 'constant' quality is not truly constant. Encoders like x264 deliberately let quality sag on the most complex frames, controlled by a quantizer-curve-compression factor (qcomp, default 0.6) that hands busy scenes fewer bits per pixel than a strictly constant quality would. It works because fast motion masks fine detail, so your eye rarely catches the artifacts hiding inside the action.

ONE STAGE OF A CHAIN β€” WHAT ARRIVES, WHAT LEAVES, WHAT BREAKS DOWNSTREAM

Where This Sits In The Encoding Pipeline

A video encoder is not one algorithm but eight stages in a fixed order, and the order is not arbitrary: each stage exists because the one before it made its job possible. This tool models one of them. The chain below links to the other seven.

Rate Control Simulator β€” chooses the quantizer for each frame to hit either a bitrate target or a quality target

Rate control is a loop rather than a step: it sits around quantization at stage 05 and keeps adjusting it, instead of running once between two neighbours.

What arrives
The measured bit cost of frames already encoded, plus a target to hit.
What leaves
A quantizer setting for the next frame, handed back to stage 05.
What the next stage assumes
It assumes it is allowed to change quantization, which is why it wraps that stage instead of following it.
What goes wrong here
Quality and bitrate cannot both be held constant. CRF fixes quality and lets bitrate rise on complex scenes; CBR fixes bitrate and lets quality sag on them. Picking one is picking which of the two is permitted to move.

Problems solved in full

  1. Deriving the 60 score for CBR's worst frame from a 4-frame buffer 6 steps

    Action scene, CRF 23, a 4-frame buffer. CBR's worst frame scores 60 out of the 85 this model allows it, and the rules are all on the page: CRF gives each frame a share of the bits proportional to its complexity, CBR pays a flat 2000 bits and tops that up from a buffer holding 4 frames' worth, and CBR's quality is 85 times the square root of supply over demand. Derive the 60.

    1. The CRF allocation is written relative to the scene's mean complexity, so averaging it hands the mean straight back. Whatever the scene and whatever the CRF, the average comes out at the 2000-bit target β€” that readout is a definition, not a measurement.

    2. The peak is the informative one. 4078 against 2000 says the busiest frame carries 2.039 times the average complexity, and the generator caps complexity at 0.95, so this scene's average complexity has to be 0.466.

    3. CBR faces the same curve. Its demand per frame is the same expression as the CRF allocation, so the frame CRF pays 4078 bits for is the frame CBR is asked 4078 bits for and hands over 2000.

    4. Covering that is the buffer's job. Full, it holds 8000 bits and lifts supply to 5040, comfortably past the 4078 the hardest frame wants β€” a full buffer would hide the peak entirely and quality would never leave 85.

    5. Quality does leave 85, so the buffer cannot be full. Set it empty instead: supply is the bare 2000, the ratio is 0.4904, its square root is 0.7003, and 85 times that is 59.5, which the panel rounds to 60. The printed minimum is the empty-buffer floor exactly.

    6. The buffer drains at whatever demand exceeds the budget, which is 2078 bits on the peak frame. 8000 bits of buffer is 3.85 frames of that. This scene's busy stretch runs 40.

    Answer

    60 is not a buffer that was sized wrong. It is a buffer that ran out. Buffer size converts into time, not into quality: divide the fill by the per-frame shortfall and you get how many frames of cover you have, which is why a burst is measured against the buffer in frames rather than in bits. Hiding a burst 40 frames long needs about 1.04 frames of buffer per frame of burst β€” roughly 40 frames of it, and the slider stops at 10. That is the case for variable bitrate in one line: CRF never has to hide the burst, it just pays for it.

  2. The 10.8-point gap between CRF and CBR at 2000 bits per frame 5 steps

    Both modes spend the same 2000 bits per frame on this scene. CRF's quality line sits at 89.8, CBR averages 79. Work out what that 10.8-point gap is bought with, and what it would cost in CRF steps.

    1. The CRF score comes from the slider alone: 45 points spread over the 22 steps from CRF 18 to CRF 40. CRF 23 is 5 steps down, so 89.8.

    2. One step is therefore 2.045 points anywhere on the scale β€” this model makes CRF quality linear, which is what lets you price the gap in steps later.

    3. The bitrates are not merely close, they are identical. CRF averages the target by construction, and CBR pays the target on every single frame, so both produce 240,000 bits over the 120 frames.

    4. Nothing in the 10.8 points between 89.8 and 79, then, is a bitrate difference. Same bits, same file size, 10.8 points apart.

    5. The gap splits in two. CBR is capped at 85 even on frames it could sail through, which costs 4.8 points against CRF's 89.8, and the remaining 6.0 points are lost on the frames where the buffer had nothing left.

    Answer

    Flat bitrate costs 10.8 quality points here, and 5.28 CRF steps would buy them back. What CBR gets for them is a peak: its largest frame is 2000 bits, exactly its average, where CRF's largest is 4078. On a link that carries 2000 bits per frame and not one more, CRF's peak frame arrives late and its 89.8 is worth nothing β€” that is the whole reason to accept the 10.8. Notice what step 3 also rules out: the allocation contains no CRF term at all, so pushing CRF to 28 would lower the score and leave the bitrate at 2000. This page shows you where the bits go, not what a quality level costs to buy.

References (1)

Example problems

  • action - Action movie: CRF bitrate spikes 3Γ— during fight sequences; CBR quality drops when buffer runs out
  • screen recording - Screen recording: CRF near-zero bits on static UI; CBR quality crashes when video playback begins
  • sports - Sports with 1-frame buffer: sustained high complexity keeps CBR quality under constant pressure
  • documentary - Documentary at CRF 30: moderate bitrate; isolated complexity spikes visible in both modes