What is CRF? Constant rate factor video encoding explained

Constant Rate Factor (CRF) is a video encoding rate-control mode that maintains consistent perceptual visual quality throughout a movie by dynamically adjusting the data allocated to every scene. Unlike legacy encoding methods that force a video into a rigid, fixed bitrate, CRF allocates bits where human eyes notice detail: complex, fast-moving scenes receive more data, while motionless, simple backgrounds consume very little.

If you have compressed a video in HandBrake, written a script in FFmpeg, or converted a home video for archival storage, you have encountered CRF. Understanding how the CRF scale operates—and why its values behave differently across software libraries and hardware encoders—is essential for achieving high video clarity without bloating your storage.

How does Constant Rate Factor (CRF) control video quality?

To appreciate why CRF improved digital video compression, you must consider the challenge of scene complexity.

A feature film is not visually uniform. A slow conversation between two actors in a sunlit kitchen contains very little visual change: the background stays motionless, facial expressions shift subtly, and broad color patches remain constant across hundreds of frames. By contrast, an action sequence featuring fireworks, splashing water, and rapid camera pans generates large amounts of chaotic, high-frequency detail.

If you encode that film using Constant Bitrate (CBR)—forcing every second of video to consume an identical 5 Mbps—two problems arise:

1. The quiet kitchen scene receives far more data than it needs, wasting storage on motionless pixels.
2. The fireworks scene is starved of data, causing the picture to dissolve into blurry blocks, edge ringing, and pixelated macroblocking artifacts.

Animation

A keyframe, then only what changed

Constant Rate Factor solves this problem through psychoacoustic and psychovisual modeling. As detailed in the official FFmpeg H.264 Video Encoding Guide, CRF modulates the encoder’s Quantization Parameter (QP) on a frame-by-frame and block-by-block basis:

• In scenes with heavy motion or visual noise, the human eye cannot perceive subtle compression loss. The encoder raises compression slightly in complex areas to prevent file sizes from ballooning.
• In clean, motionless scenes with smooth gradients, the human eye quickly spots compression banding or blockiness. The encoder lowers compression, allocating extra bits to preserve sharp textures.

The result is uniform perceptual quality from opening credits to final fade-out. You select the quality level you want, and the encoder determines the data rate needed for each scene.

What are the recommended CRF values for x264 and x265?

In the leading open-source software encoders—libx264 for H.264 and libx265 for HEVC—the CRF scale operates as an inverted logarithmic integer scale from 0 to 51:

• CRF 0: Mathematically lossless compression (identical pixel values to the uncompressed source, resulting in very large file sizes).
• CRF 17 to 18: Visually lossless quality (indistinguishable from the master source under normal viewing conditions; standard for archival preservation).
• CRF 20 to 23: High quality (subtle compression artifacts visible only when zooming into freeze-frames; practical for everyday viewing and home libraries).
• CRF 24 to 28: Moderate quality (noticeable softening in fine textures; ideal for portable mobile devices or internet uploads where small file size is paramount).
• CRF 51: Lowest quality setting (severe macroblocking, unsuitable for normal viewing).

A practical rule of thumb governs the x264 and x265 scales: an adjustment of plus or minus 6 roughly halves or doubles the final video bitrate. For example, encoding a movie at CRF 18 produces a file roughly twice as large as the same movie encoded at CRF 24:

• CRF 12: Roughly 4× the default bitrate (very large file)
• CRF 18: Roughly 2× the default bitrate (visually lossless archival)
• CRF 23: Baseline 1× bitrate (x264 default)
• CRF 29: Roughly 0.5× the default bitrate (compact mobile file)

Why x265 uses a default CRF of 28

A common source of confusion is the differing default values between encoders:

• libx264 defaults to CRF 23
• libx265 defaults to CRF 28

Because HEVC (H.265) compresses video roughly 50% more efficiently than H.264, setting a CRF of 28 in libx265 achieves visual fidelity comparable to a CRF of 23 in libx264, while producing a significantly smaller file. If you set libx265 to CRF 23 assuming it represents the same quality as x264, you will generate an unnecessarily large file that wastes disk space.

For next-generation AV1 encoders like SVT-AV1, the CRF scale is expanded from 0 to 63, with recommended quality targets typically between 24 and 32. To understand how these underlying codecs differ, see our guide comparing H.264 vs H.265 vs AV1.

How does HandBrake’s RF slider differ from software CRF?

HandBrake is a widely used graphical video transcoder on macOS. In HandBrake’s Video tab, the rate-control slider is labeled Constant Quality (RF), which stands for Rate Factor.

While HandBrake uses the standard CRF scale when you choose software encoders like H.264 (x264) or H.265 (x265), a trap awaits users who switch to Apple’s hardware VideoToolbox encoders.

As documented in HandBrake’s VideoToolbox Documentation, the underlying mathematical scale reverses between software and hardware pipelines:

In HandBrake’s interface, moving the slider to the right always indicates higher quality. However, if you inspect the numbers or write command-line scripts for HandBrakeCLI, the scales are incompatible:

• If you set an RF of 22 in x264, you get a crisp, visually lossless 1080p video.
• If you switch the encoder to H.265 (VideoToolbox) and leave the value set to 22, VideoToolbox interprets 22 on a 0-to-100 scale. The resulting video will be crushed into a blocky blur because 22 represents extreme low-bitrate compression in Apple’s hardware engine.

For hardware encoding on Apple Silicon Macs, target quality values between 50 and 65 in VideoToolbox to achieve clean results. To master HandBrake’s settings on macOS, read our walkthrough on HandBrake on Mac.

Why does CRF beat constant bitrate for archiving video?

When archiving movies, TV series, or home video clips to a local drive, CRF is generally superior to two-pass variable bitrate (VBR) or constant bitrate (CBR):

1. Consistent Quality Without Guesswork: With bitrate-targeted encoding (such as targeting 4,000 kbps), you must guess how much data a video needs before inspecting it. An action film will look starved of bits, while an animation will waste storage. With CRF, you set your desired visual fidelity once, and the encoder delivers that level of clarity regardless of the source footage.
2. Single-Pass Efficiency: Traditional two-pass VBR requires scanning the entire video file from beginning to end on pass one to create a complexity log, then encoding the file on pass two. CRF achieves effective bit distribution in a single pass, saving hours of processing time on long video queues.
3. Storage Economy: Animated movies, desktop screen recordings, and low-motion dramas encoded with CRF compress down to compact file sizes automatically, leaving disk space available for visually complex films that need higher bitrates.

To learn how to calculate bitrates and estimate file sizes, read our explainer on what bitrate is.

Why do streaming services use bitrate caps instead of pure CRF?

If CRF is efficient, why do commercial streaming services like Netflix, YouTube, and Apple TV+ not stream in pure Constant Rate Factor?

The reason is network bandwidth limits. Because pure CRF is unconstrained, a sudden burst of high visual complexity—such as confetti falling or rippling water—can cause the bitrate to spike from 10 Mbps to 80 Mbps for several seconds.

When a video file lives locally on your Mac’s internal SSD, an 80 Mbps burst is trivial to handle. But over a residential Wi-Fi connection or cellular network, an 80 Mbps spike can exceed available bandwidth, draining the playback buffer and causing the video to freeze.

To prevent buffering, streaming services use Constrained CRF or capped Variable Bitrate managed by Video Buffer Verifier (VBV) parameters:

• The encoder sets a target CRF for visual consistency.
• It pairs that CRF with a maximum bitrate cap (-maxrate) and a buffer size constraint (-bufsize).
• If a complex scene would normally demand 70 Mbps, the VBV mechanism clamps the peak down to the cap, trading temporary sharpness in that scene to guarantee uninterrupted playback.

How should you evaluate your encoded video on a Mac?

After compressing a video using CRF, evaluating the result involves more than checking the file size in Finder. You must inspect the image critically in a capable video player.

Look closely at vulnerable visual regions:

• High-frequency textures: Inspect grain, foliage, brickwork, and hair. If your CRF number was too high, these areas will appear soft or smudged.
• Fast motion: Watch camera pans and quick action cuts. Ensure that moving edges do not display ringing halos or square block artifacts.
• Dark shadows and gradients: Dark scenes in 8-bit encodes are the first to exhibit color banding. If you see harsh contours across shadows, consider encoding in 10-bit color, which provides smoother gradations.

MacLC provides keyboard shortcuts for fine-tuning playback, including track synchronization (F / G for audio delay and H / J for subtitle delay), snapshots (⌘⌥S), and picture styles that preserve mastering intent.

To master desktop video tools and command-line encoding workflows, read our tutorials on compressing video on a Mac and using FFmpeg on macOS.

If you want a dependable, open-source video player that shows you exactly how your re-encoded files look and sound on Apple Silicon, download MacLC from the download page. It runs natively with zero bloat, supports major compression standards, and renders your media library with high visual accuracy.