In a blog full of wonky compression articles, this could be the wonkiest article of all. If you’re not using capped CRF encoding, or considering the same, it’s almost certainly not of interest. If you are using capped CRF encoding (for constant rate factor), however, you almost certainly will find it interesting and perhaps even illuminating.
A quick background note. Late last year, I consulted with a large OTT shop that used capped CRF encoding with a CRF value of 19 for the top files in the encoding ladder. Most of the analysis shown below was for this client (who approved my discussion in an article). I hadn’t written this article yet because I figured it was too obscure for most readers.
This morning, however, I downloaded a video from Vimeo and noticed they were encoding with capped CRF with a CRF value of 20, which you can see in MediaInfo below. Why was I trolling Vimeo? Because they promised a few months ago, with great fanfare, that they were encoding their staff picks using the AV1 codec. Periodically, I download a file to see if this is so; so far, no AV1 encodes. This doesn’t mean that Vimeo isn’t using AV1, it could be that my download tool simply doesn’t capture the AV1 encode.
But, I did notice that Vimeo was using CRF 20, which IMHO, is suboptimal and prompted the resurrection of this article. No disrespect intended for Vimeo, who has a fabulous team of encoding professionals. But here’s what I’m thinking and why.
By way of background, most producers use capped CRF as a DIY per-title encoding technique. When you encode with CRF and no cap, FFmpeg prioritizes quality over bitrate and varies the bitrate to deliver the specified quality, which ranges from 1-51 with lower numbers delivering higher quality. See here for a complete explanation of capped CRF including FFmpeg command strings. CBR and VBR encodes do the reverse, and adjust quality to meet the specified data rate.
Of course, you can’t use CRF-only encodes for streaming since limiting the data rate is key to deliverability. So, you add a cap or maximum bitrate. To produce capped CRF, you specify a CRF value and a maximum rate and buffer size, which are also highlighted in the MediaInfo screen above. Essentially, Vimeo is telling FFmpeg to encode to a CRF value of 20 with a max rate of 5500 and a VBV buffer of 15000 (see here for more on VBV buffer).
One of the files I downloaded was Light Speed, and it’s shown in Bitrate Viewer below. You see that the average bitrate is around 4664 kbps, but that the average data rate, shown by the faint blue line, hovers over 5 Mbps most of the time. When there’s substantial space below the line, as in those areas pointed to with lines from Controlled by CRF, it means that CRF is setting the quality level. When the data rate is pushed against 5.5 Mbps, it’s the cap enforcing the limit.
What’s the problem with using CRF 20? Well, nothing if you don’t care about spending too much on bandwidth. But if you’re using capped CRF to reduce bandwidth on easy-to-encode clips, you can probably use a higher value (and deliver slightly lower quality) and reduce bandwidth without anyone noticing.
VMAF 93 = Good Enough
A couple of points on VMAF, then I’ll charge ahead. First, as CTO of RealNetworks Reza Rassool established here, a VMAF score of 93 means “that the vast majority of the audience [will find the content] either indistinguishable from original or with noticeable but not annoying distortion.” So, if your scores are 93 – 95, your video is likely “good enough.” If it’s higher, you’re spending money to deliver additional quality that no one will notice.
The other point about VMAF is that encoding with CRF 23 and x264 delivers an average VMAF score of 95.96 in the test clips I used in my book Video Encoding by the Numbers, as you can see in the table below. So, if you’re using CRF 20, you’re almost certainly delivering a VMAF quality that’s higher than 93-95 (since lower CRF values deliver higher quality). This means that the data rate on all videos that you distribute is likely too high, or at least higher than it needs to be.
You see this in the table below, which shows most of the same clips encoded at CRF 19 with a cap of 5 Mbps. The easy-to-encode clips, where the data rate is largely controlled by the CRF value, have a CMAF score of 96.90, which is unnecessarily high. The hard-to-encode clips controlled by the cap are still well north of 93, so their quality is OK.
What happens when you use higher CRF values with the same cap? That’s shown below (click the table to see it at full resolution). At CRF 23, you reduce the data rate of the easy-to-encode clips by 33% while reducing VMAF from 96.9 to 96.15, which is irrelevant. So, you’ve achieved one key goal of per-title encoding, which is reducing the data rate on easy-to-encode clips.
The data rate and quality deltas between CRF 19 and CRF 23 for the hard-to-encode clips are much lower because the data rate cap controls bitrate and quality with these clips, not CRF. Still, at CRF 23 you reduce the bitrate by 8.57% but only reduce the VMAF score from 94.68 to 94.41.
The bottom line is that if you’re encoding with capped CRF and your CRF value is lower than 23, you’re probably wasting bandwidth on your easy-to-encode clips. Run some tests at CRF 23, and see how that impacts bandwidth and noticeable quality.
For more information on computing and using video quality metrics, I have a video course with over 3 hours of video instruction. For more on the course, click the course image below, or click here.