Technical Brief: Switch from CBR to VBR to Improve Overall Quality and Avoid Transient Quality Issues

Summary (The MPD)

Many streaming producers use constant bitrate encoding (CBR) as a bitrate control technique, either in an attempt to create the most efficient stream for delivery, or to comply with perceived Apple requirements for HTTP Live Streaming (HLS). However, CBR delivers the lowest overall quality of all bitrate control techniques and introduces the potential for dramatic transient quality issues like those shown in Figure 1. (You can download a PDF copy of this Technical Brief, by clicking here). 


Figure 1. Comparison of CBR vs. VBR encoding (click image for full size view). 

A recent survey indicates that many producers have switched over to variable bitrate encoding (VBR) and are ignoring the aforementioned Apple recommendations. Testing reveals that 110% constrained VBR avoids the transient quality issues caused by CBR encoding. Producers still using CBR should consider switching over to constrained VBR to avoid these transient quality issues and improve overall video quality.

Segment 1: Bitrate control is one of the most fundamental encoding options selected for each compressed file

Whenever you encode a file for streaming distribution, you choose a bitrate and a bitrate control technique. This is shown in Figure 2, from the Adobe Media Encoder.


Figure 2. Bitrate control techniques available in the Adobe Media Encoder.

The two most common techniques are:

•          Constant bitrate encoding (CBR), where the same bitrate is applied to the entire file, irrespective of scene complexity. With CBR, you set the target bitrate (Figure 2) but not the Maximum, because the bitrate is not supposed to vary significantly, though it typically does to some limited degree, as shown in Figure 3.

Figure 3 shows a file encoded using CBR. As you can see in the legend on the right, the average bitrate is 4936 kbps, while the peak is 5557 kbps. The wavy light blue line is the floating data rate, which varies minimally over the duration of the file. The individual columns are the size of each encoded Group of Pictures within the file, with a keyframe every three seconds in this 29.97fps file.


Figure 3.  A CBR-encoded file in Bitrate Viewer.

Note that CBR is never a complete flatline; a variability of about 5-10% is normal.

•          Variable bitrate encoding (VBR), where the same overall target data rate is met, but the data rate is varied over the duration of the file to match scene complexity. With VBR, you set the Target and Maximum (Figure 2), and in some applications, the minimum as well. When you set a maximum, the VBR encoding is considered constrained, and VBR is often described by the percentage of the constraint. In Figure 2, the Maximum Bitrate is 2.4 Mbps, or 200% of the Target Bitrate of 1.2 Mbps. This technique would be called 200% constrained VBR.

Figure 4 shows the same file as Figure 3 encoded using 200% constrained VBR to the same target bitrate of 5000 kbps. The average bitrate is about the same (4988 kbps vs. 4936 kbps), but the peak bit rate is 9301 kbps, not quite 200% but in the ballpark. The wavy blue data rate line varies much more significantly than in Figure 3, with low rates at the start, and peaks throughout.


Figure 4. The same file encoded using 200% constrained VBR.

•          Many producers default to CBR for some or all of their encoding. In the early days of streaming, the connections were so constrained that CBR was recommended to avoid data rate spikes that could stall smooth playback. In Apple Technote TN2224, Apple states “Bit Rate Variability - Should not exceed 10% of target bitrate.” More ominously, Apple’s Media Stream Validator, a tool used to test HLS streams, creates a warning if any stream segment bitrate varies from the target bitrate by over 10%. Not surprisingly, in a recent survey by the Streaming Learning Center, 11 of 16 respondents indicated that they were still using CBR encoding for some of their streams (Figure 5). Admittedly, the number of respondents is too small to be statistically significant, though the responses are valid for informational purposes.


Figure 5. Eleven of 16 respondents were still using CBR on some of their streams, as well as other techniques.

As you can see in Figure 5, other bitrate control techniques exist, including Constant Rate Factor (CRF) and Capped CRF. However, since they are best used in very limited instances (mostly synthetic content like screencams and PowerPoint videos with audio) they are not included in this discussion.

Segment 2. CBR Delivers Overall Lower Quality than VBR 

Table 1 shows the results of one set of quality comparisons run for Jan Ozer’s upcoming book, Encoding by the Numbers, which is due out in the summer of ‘2016. These tests involved files encoded to 720p resolution at 2 Mbps using FFmpeg, with VQM scores measured by the Moscow University Video Quality Measurement Tool (VQMT). With VQM, lower scores are better, and in the table, scores in red are the worst, scores in green the best.


Table 1. PSNR quality comparison for different bitrate control techniques.

Note the quality delta columns in Table 1. The first shows the total quality difference between the lowest and highest quality file in the group. The second shows the quality difference between the clips encoded using 110% and 200% constrained VBR. As you’ll see, producers can avoid transient quality issues and stay within Apple recommendations by using 110% constrained VBR. However, producers seeking the highest possible quality file, and unconcerned with Apple’s recommendations, should use 200% constrained VBR.

In all test cases, 2 Pass CBR delivered the worst quality, and in five of six, 200% constrained VBR delivered the highest quality. The sole exception was the talking head clip, where 1 pass CBR delivered the highest quality. This result appears to be an anomaly; in similar tests performed on three-low motion, talking-head clips, the results were consistent with all other files in Table 1. The highest variability was seen in the Big Buck Bunny clip, which showed a 14.54% quality differential between the lowest and highest quality clips (Total Quality Delta column).

The overall quality differential is otherwise relatively minor in most other clips. In fact, it’s probably not even observable during normal playback. However, in some instances, CBR files can exhibit a more serious problem; the transient quality drops shown in Figure 1.

Segment 3: CBR’s Transient Quality Issues Are Much More Concerning 

When you’re encoding challenging clips to aggressive parameters, CBR encoding can cause severe, transient quality issues like those shown in Figure 1. Figure 6 is the Results Visualization screen from the Moscow University VQMT tool, which shows the VQM scores (lower scores better) for two files. The file in red was encoded using 110% constrained VBR, while the file in blue is CBR. The circled data spikes show frames, or groups of frames, where the quality of the CBR file suffered dramatically as compared to the 110% constrained VBR file. The worst of these differentials is shown in Figure 1.


Figure 6. The data rate spikes in the bottom figure show frames, or groups of frames, where CBR quality is dramatically worse than 110% constrained.

What’s interesting is that the peak bit rate for the CBR file actually exceeds that of the VBR file. You can see this in Figure 7, which shows Bitrate Viewer analyzing the CBR file (on top) and the VBR file. The sideboards on the right show the average and peak bitrates for both files. The average is nearly identical, while the peak rate for the CBR file is 2623 kbps compared to 2539 kbps for the 110% constrained VBR file (but see note 5 below). Whether your concern is streaming efficiency, heeding Apple’s 110% variability recommendations, or both, constrained VBR achieves a superior result, while also delivering overall higher quality and avoiding the transient quality drops seen in the CBR file.


Figure 7. Bitrate Viewer analyzing the CBR file up top and 110% constrained VBR file on the bottom.

You can watch a short video illustrating and explaining these issues immediately below.


This video illustrates the transient quality issues sometimes seen with CBR video. Best viewed in full screen (click icon on lower right within playback window).  

Perhaps not surprisingly, our survey results revealed that the most common percentage constraint used by respondents was 110% of the target, though admittedly, as with the survey results in general, the number of respondents is too small to be statistically significant.


Figure 8. 110% of the target was the most common constraint.

Segment 4: Many Producers Ignore Apple’s 110% Variability Recommendation 

Figure 9 shows some of the more interesting results of the survey. That is, of those producing HLS files, the majority of producers ignore Apple’s recommendation entirely. Interestingly, the one demographic question asked in the survey was the number of video files produced each week. Ten respondents indicated that they were producing over 100 files a week; of this group, five followed Apple’s recommendation religiously, five ignored it completely.


Figure 9. Most producers ignore Apple’s recommendation.

An interesting follow up question would have been whether the respondents who ignored the restriction were distributing to iOS devices via an app. Unfortunately, we did not ask that question, leaving open the concern that Apple will reject apps when video played by the app does not meet the 110% variability requirement.

Segment 5: Conclusions

1. In all tests, CBR delivered the lowest overall quality of all bitrate alternatives.

2. In all tests but one, constrained VBR delivered the highest quality

3. With challenging footage and aggressive encoding parameters, CBR-encoded video can exhibit transient quality drops, sometimes dramatic.

4. Producing using 110% constrained VBR seems to avoid these quality issues without introducing significant data rate variability.

5. In most instances, encoding with 200% constrained VBR delivers the maximum quality.

6. Many producers are ignoring Apple’s recommendation to produce HLS files with a maximum of 110% stream variability.

Segment 6: Recommendations

1. Producers who are currently using CBR for some, or all of their encodes, should consider switching to constrained VBR.

•   110% constrained VBR should avoid transient quality issues.

•   200% constrained VBR will deliver the absolute best quality.

2. Producers distributing HLS video via an app should probably choose 110% constrained VBR to avoid App Store approval issues when initially submitting or when submitting updates. Those shipping for browser-based desktop and mobile playback (e.g. no app) should consider 200% constrained VBR.

3. These results will vary by codec and encoding tool. As described below, we produced all files for these tests in FFmpeg using the x264 codec. We have observed the transient quality issues with CBR files in other x264-based encoding tools, but they may not appear in all encoding tools. 

4. Any major encoding change such as those recommended herein should not be implemented without testing to ensure quality and playability.

Appendix I: How We Tested 

Here is a brief description of the procedures used for these tests.

1.         We produced all files using FFmpeg on an HP Z840 workstation running Windows 7 Professional with 64 GB of RAM.

2.         General encoding parameters were keyframes every 3 seconds and the veryslow preset.

3.         We produced CBR files by using the same target bitrate, max bitrate, and a buffer setting of one second of video. For 4 mbps targets, the string was:

-b:v 4000k 

-maxrate 4000k

-bufsize 4000k  

4.         We produced constrained VBR files by adjusting the max rate setting, and by using a buffer value of 1 second. For a 4 mbps target with 110% constrained CBR, the string was:

-b:v 4000k 

-maxrate 4400k

-bufsize 4000k

For both CBR and VBR, encoding with a larger buffer improved stream quality, but it also increased stream variability.

5.         We produced the CBR files analyzed in Figures 6 and 7, and in the video, using 1-pass CBR, which increased the quality of the file compared to 2-pass (see Table 1), but also increased file variability. Encoding with 1-pass CBR also produced files well below the target, so we had to encode multiple times at increasingly higher rates to meet the target data rate. Using 2-pass CBR encoding delivers slightly lower quality files, but also greater data rate accuracy and reduced stream variability.

6.         We verified that the target data rate of all files were within 5% of the target.

7.         We produced all quality scores included above using the Moscow University Video Quality Measurement Tool.

About the Streaming Learning Center

The Streaming Learning Center is a premiere resource for companies seeking advice or training on cloud or on-premise encoder selection, preset creation, video quality optimization, adaptive bitrate distribution, and associated topics. Please contact Jan Ozer at for more information about these services.

Comments (7)

Said this on 3-15-2016 At 08:13 am

We are one of the providers which have been applying the 110% contrained VBR for HLS streams for more than 2 years. Point is not to be strictly in line with Apple recommendations for app submission (Apple will approve an app with warnings in validator - we've had many on iOS and tvOS), but of course to get best VQ as possible (especially on linear streams) and to get the heuristics used to switch from one stream still to work as expected, on Apple HLS players, but also on others (very few players conform to HLSv1 guidelines nowadays, especially when we consider server-side ad insertion). Anyhow, when using 110% constraints, encoders won't follow strictly that rule (especially on lowest bitrates), they'll try as much as possible to. 

Said this on 3-15-2016 At 12:35 pm

Thanks for your note and for taking the survey.

Said this on 3-17-2016 At 01:16 pm

Doing VBR for stored content like blurays, it is quite straightforward. But for streaming apps, it is not just about encoding but also carefully managing the playback buffer. I had a paper last year in IBC explaining this and showing results. 

Also, Apple has new recommendations:

For tv now, but I suspect they will do it for smaller screens soon, too.

Said this on 3-17-2016 At 01:25 pm

Good stuff, I hadn't seen the Apple TV specs.

Could you include a link to your paper?


Said this on 3-17-2016 At 01:50 pm

Sure, the paper is in IBC proceedings:

I will be happy to send you the pdf if you could let me know the preferred email address. The prezo is here, though:

Also have a look at

I am working on a more detailed paper right now, would welcome any feedback.

Sandy MacInnis
Said this on 3-17-2016 At 03:37 pm

Using VBR with a peak rate that is much greater than the average is of course attractive in terms of picture quality, but it's a problem when the network throughput is constrained to significantly less than that peak, such as the nominal rate plus 10%. To put it another way, if the server and client knew that the network could support 100% greater bit rate than the nominal, they could just use that higher bit rate, unless's another reason not to.

In some systems there is another constraint such as the cost to the operator of the aggregate network usage. When this applies and the peak bit rate is not constrained by network throughput, then VBR as described makes sense.

But in many cases there is a weak link in the network, such as throughput of a crowded WiFi hotspot, or a weak WiFi link with low throughput, so the peak rate may be an issue.

thierry fautier
Said this on 5-17-2016 At 10:32 pm

this VBR ABR technique makes a lot of sense, see recent announcements from Netflix and YouTube, looks like Apple is the only one not  liking it, infra problems ?

we talk here about http transfers, so basically files transfers, Internet can cope with that, the danger of course is if a chunk can not go though, it will be delayed, and then buffering will be observed. But if i can get 50% in average vs strict CBR a la HLSO, iso encoding at 1M/s, i encode at 500k/s in averge and allow peaks at 1M, then all is good. did i miss something ?

Post a Comment
* Your Name:
* Your Email:
(not publicly displayed)
Reply Notification:
Approval Notification:
* Security Image:
Security Image Generate new
Copy the numbers and letters from the security image:
* Message: