CRF Guide (Constant Rate Factor in x264, x265 and libvpx)

What is the Constant Rate Factor?

The Constant Rate Factor (CRF) is the default quality (and rate control) setting for the x264 and x265 encoders, and it’s also available for libvpx. With x264 and x265, you can set the values between 0 and 51, where lower values would result in better quality, at the expense of higher file sizes. Higher values mean more compression, but at some point you will notice the quality degradation.

For x264, sane values are between 18 and 28. The default is 23, so you can use this as a starting point.

With ffmpeg, it’d look like this:

ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4

For x265, the default CRF is 28:

ffmpeg -i input.mp4 -c:v libx265 -crf 28 output.mp4

For libvpx, there is no default, and CRF can range between 0 and 63. 31 is recommended for 1080p HD video:

ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 31 -b:v 0 output.mkv

If you’re unsure about what CRF to use, begin with the default and change it according to your subjective impression of the output. Is the quality good enough? No? Then set a lower CRF. Is the file size too high? Choose a higher CRF. A change of ±6 should result in about half/double the file size, although your results might vary.

You should use CRF encoding primarly for offline file storage, in order to achieve the most optimal encodes. For other applications, other rate control modes are recommended. In video streaming, for example, CRF can be used in a constrained/capped mode to prevent bitrate spikes.

What bitrates will I get?

To give you an estimation of the bitrates to be expected for clips with different resolutions, here’s a figure showing the average bitrate in MBit/s for four one-minute video clips with different encoding complexity, encoded with x264 and different CRF values:

As you can see, the maximum rate can range between 10 and 25 MBit/s for a 2160p encode at CRF 23. For other CRFs and resolutions, the rates vary accordingly. You can clearly see the logarithmic relationship between CRF and bitrate.

CRF versus Constant QP

CRF is a “constant quality” encoding mode, as opposed to constant bitrate (CBR). Typically you would achieve constant quality by compressing every frame of the same type the same amount, that is, throwing away the same (relative) amount of information. In tech terminology, you maintain a constant QP (quantization parameter). The quantization parameter defines how much information to discard from a given block of pixels (a Macroblock). This typically leads to a hugely varying bitrate over the entire sequence.

Constant Rate Factor is a little more sophisticated than that. It will compress different frames by different amounts, thus varying the QP as necessary to maintain a certain level of perceived quality. It does this by taking motion into account. A constant QP encode at QP=18 will stay at QP=18 regardless of the frame (there is some small offset for different frame types, but it is negligible here). Constant Rate Factor at CRF=18 will increase the QP to, say, 20, for high motion frames (compressing them more) and lower it down to 16 for low motion parts of the sequence. This will essentially change the bitrate allocation over time.

For example, here is a figure (from another post of mine) that shows how the bitrate changes for two video clips encoded at different levels (17, 23) of constant QP or CRF:

The line for CRF is always lower than the line for CQP; it means that the encoder can save bits, while retaining perceptual quality, whereas with CQP, you waste a little bit of space. This effect is quite pronounced in the first video clip, for example.

Why is motion so important?

The human eye perceives more detail in still objects than when they’re in motion. Because of this, a video encoder can apply more compression (drop more detail) when things are moving, and apply less compression (retain more detail) when things are still.

In layperson’s terms, this is because your visual system will be “distracted” by everything going on, and won’t have the image on screen for enough time to see the heavier compression. Slightly more technically speaking, high motion “masks” the presence of compression artifacts like blocking. On the other hand, when a frame doesn’t have a lot of motion, you will (simply put) have more time to look at the image, and there will be nothing to distract you or mask any artifacts, so you want the frame to be as little compressed as possible. With low motion, compression artifacts become more salient (visually apparent) and thus more distracting.

You may ask if constant QP isn’t really better quality in the end? No, the perceived quality is the same, but essentially it wastes space by compressing less in areas you really won’t notice.

Practically speaking, many people always use CRF for single-pass encodes and argue there is no reason to ever use CQP. Another good argument for using CRF is that it is the default rate control mode chosen by the developers of x264 and x265.

What about video quality metrics?

If you had only simple ways at hand to compare the quality of video sequences (e.g., based on a per-frame measurement of signal to noise ratio, PSNR), you may look at a CRF encoding and say it was lower quality than the CQP variant. But if you’re a human being, subjectively, the CRF copy will look equal or better to the CQP version. It least compresses the parts where you see details the most, and most compresses the parts where you see details the least. That means that while the average quality as objectively gauged by PSNR goes slightly down, the perceptible video quality goes up.

This is also another argument against using simple metrics such as PSNR or SSIM to judge video quality: they cannot take into account perceptual effects like motion, since they only look at individual frames. More perceptually-based metrics like VQM or VMAF are better choices for evaluating video degradations.

How do quality and bitrate relate to each other?

Not all video clips are equally “easy” to compress. Low motion and smooth gradients are easy to compress, whereas high motion and lots of spatial details are more demanding on an encoder. When I say “easy” or “hard”, I mean that an easy source will have better perceptual quality at the same bitrate than a source that is hard to encode.

CRF takes care of this problem: with different videos, different CRF levels result in different bitrates. (In fact, you cannot reliably estimate what the resulting bitrate for a given CRF will be, unless you know more about that source, which is what YouTube is doing.)

For example, if you set CRF 23, you may end up with 1,500 kBit/s for one source, but only 1,000 kBit/s for the other. They should look the same in terms of quality, though. With CRF, you are saying “use whatever bitrate is necessary to preserve this much detail.” It’s not a 1-to-1 thing.

The cloud encoding service Bitmovin also uses CRF to gauge the complexity of a clip before encoding it.

Note that if your CRF is too high—for example if you use a CRF of 30—you’re going to see blocking on high-motion because the bitrate in these parts will simply be too low. The encoder will use a QP of (for example) 32 for the more complex parts, which is way too heavy a quantizer. As mentioned in the beginning, choose the CRF depending on what level of quality you want.

Why do you still see some blocky stuff on TV or cable?

Why are there blocky cable or satellite broadcasts? Or even online video streams? The problem is that they are using a too low bitrate for some parts of the video. Especially in broadcasting, streaming is done at a constant bitrate, which does not allow for variations to adapt to the level of motion. Therefore, those TV broadcasts get blocky because the complex things they’re displaying require more bits than the broadcaster has chosen to give them. They only say “preserve as much detail as you can while never going above this high a bitrate no matter how complicated things get.”

Streaming nowadays is done a little more cleverly. YouTube or Netflix are using 2-pass or even 3-pass algorithms, where in the latter, a CRF encode for a given source determines the best bitrate at which to 2-pass encode your stream. They can make sure that enough bitrate is reserved for complex scenes while not exceeding your bandwidth.

You can learn more about rate control modes in another post of mine.