原文链接：https://slhck.info/video/2017/03/01/rate-control.html

What is “rate control”? It’s what a video encoder does when it decides how many bits to spend for a given frame. The goal of (lossy) video encoding is to save as many bits as possible, reducing the file size over the original input file, while retaining as much quality as possible. Rate control is a crucial step in determining that tradeoff between size and quality.

Rate control comes in many forms—you’ll recognize the terms “1-pass” and “2-pass”, “CBR” and “VBR”, maybe you know about “VBV Encoding” or “CRF”.

Why should you care? Often enough, you see examples of video encoding commands that apply the wrong kind of rate control mode or wrong bitrates. This post is a brief guide on the different modes; it explains when you’d use which, as an end user. Note that this is not about the nitty-gritty details of Rate-Distortion Optimization.

Preamble: Variable vs. Constant Bitrate

Many people are more familiar with rate control in audio encoders, especially those who—like me—grew up with MP3s. To rip our CDs, we had been using Constant Bitrate (CBR) encoding for a while, when later, Variable Bitrate (VBR) encoding came along. Variable bitrate ensured that you’d achieve the lowest possible file size at the highest possible quality under the given constraints (as set by the VBR quality level).

Simply put, VBR lets the encoder use more bits for “stuff that is hard to encode” and save bits for the parts of the file that are easy to compress. What is hard and easy in terms of compression? Lots of motion in a video for example require more bits to encode, since the differences between adjacent video frames will be larger. High spatial details and complex textures are also hard to encode.

前言：Variable vs. Constant Bitrate (可变码率和固定码率)

简单地说，VBR让编码器为难编码的图像使用更大的bits，而为能简单压缩的节约bits. 那对于编码压缩什么是简单和难的呢？如果一个视频中存在大量运动，那么视频中相邻的视频图像帧之间的差异就会更大。同时，高空间细节和复杂的纹理也很难编码。

What is your encoding scenario?

Choosing a rate control mode strongly depends on your use case. In general, there are a number of different scenarios that all impact the way you should design your encoding pipeline:

Archival — You want to compress a file for storing it in your archive, for example on an external hard drive or on your network storage. The file should have the best possible quality at the lowest possible file size, but you don’t care about the exact size.
Streaming — You want to send a file over the Internet, using typical Video-on-Demand (VoD) streaming solutions such as HTTP progressive download or HTTP Adaptive Streaming. You need to make sure that the file doesn’t exceed a certain bitrate, or you need to provide different representations of the same file at different nominal bitrates (for Adaptive Streaming)
Live Streaming — Like 2., but you want the encoding to be done as fast as possible, and you don’t have any knowledge of the content beforehand.
Encoding for Devices — You want to put your file on a DVD, a Blu-ray, et cetera. You want to ensure that the file ends up having a certain size.

Knowing the scenario helps you choose a rate control mode.

你的编码场景是什么？

1，归档(存储)：这种场景我们可能要求文件的大小应该在尽可能小的体积下具有尽可能好的质量，但是您并不关心确切的大小。

2，流：您希望通过Internet发送文件，使用典型的视频点播(VoD)流媒体解决方案，如HTTP渐进下载或HTTP自适应流媒体。您需要确保文件不超过特定的比特率，或者您需要以不同的名义比特率提供相同文件的不同表示(用于自适应流)。

3，实时流媒体(直播):你希望尽快的完成编码，同时你也事先对视频内容未知。

4，编码设备：你想把你的文件做成DVD，蓝光等等。您希望确保文件最终具有特定的大小。

Rate Control Modes

Now, let’s dive into the different modes. I will be basing my post on the modes supported by the popular H.264 and H.265 encoders x264 and x265, as well as libvpx, as available in ffmpeg. You can find more information on the options supported by the encoders in the documentation.

For x265, you may have to compile ffmpeg with --enable-libx265. With x265, not all parameters can be passed directly, so you have to use the -x265-params option. For libvpx, ffmpeg needs to be compiled with --enable-libvpx.

A word of caution: Encoders like x264 by default do not unnecessarily “stuff” frames with bits. This means that if you have a scene that is very easy to encode, your bitrate may always end up lower than the one you specified. Don’t worry about this—just keep in mind that there’s no point in achieving an exact target bitrate if it’s wasteful.

码率控制模式

需要注意的是:像x264这样的编码器在默认情况下并不会不必要地用比特“填充”帧。这意味着如果你有一个非常容易编码的场景，你的比特率可能总是低于你指定的。不要担心这个——只要记住，如果浪费的话，实现一个精确的比特率是没有意义的。

Constant QP (CQP)

The Quantization Parameter controls the amount of compression for every macroblock in a frame. Large values mean that there will be higher quantization, more compression, and lower quality. Lower values mean the opposite. QP ranges from 0 to 51 in H.264, and you can easily set a fixed QP for your entire encoding process with x264 and x265. Note: libvpx does not have a fixed QP mode.

ffmpeg -i <input> -c:v libx264 -qp 23 <output>ffmpeg -i <input> -c:v libx265 -x265-params qp=23 <output>

To know more about the idea behind QP, you can read this tutorial (if you’re not afraid of some maths).

Unless you know what you’re doing and you explicitly want this, it is suggested not use this mode! Setting a fixed QP means that the resulting bitrate will be varying strongly depending on each scene’s complexity, and it will result in rather inefficient encodes for your input video. The quality will be good if you set a low enough QP, but in contrast to CRF (see below), you may waste space, or you have no control of the actual bitrate.

Good for: Video encoding research, or if you have no CRF mode
Bad for: Almost anything else

Note that Netflix proposes using fixed-QP encoding for its per-shot encoding optimization to achieve optimal encodes for each scene. This however requires a lot of processing and careful assembly of the individual encoded shots, so it’s not a “one size fits all” method you should use unless you have the whole framework implemented.

1，Constant QP(CQP) :固定视频量化参数

ffmpeg使用： ffmpeg -i <input> -c:v libx264 -qp 23 <output>

量化参数控制帧中每个宏块的压缩量.较大的值意味着更高的量化、更多的压缩和更低的质量.QP在H.264中取值范围从0到51，使用x264和x265可以轻松地为整个编码过程设置一个固定的QP。注意:libvpx没有固定的QP模式。

除非您知道自己在做什么，并且明确地希望这样，否则不要使用此模式!设置一个固定的QP意味着根据每个场景的复杂性，产生的比特率会有很大的变化，这将导致输入视频的编码效率很低。您可能会浪费空间，而且无法控制实际的比特率。

Good for: Video encoding research，好处是针对视频研究的场景
Bad for: Almost anything else 大部分的场景下都是不好的

请注意，Netflix建议使用固定qp编码对每个镜头进行编码优化，以实现每个场景的最佳编码。然而，这需要大量的处理和个别编码镜头的仔细组装，所以它不是一个“一刀切”的方法，你应该使用，除非你有整个框架的实现。

Netflix参考链接：

https://medium.com/netflix-techblog/dynamic-optimizer-a-perceptual-video-encoding-optimization-framework-e19f1e3a277f

Average Bitrate (ABR, also “target bitrate”)

Here, we give the encoder a target bitrate and expect it to figure out how to reach that bitrate:

ffmpeg -i <input> -c:v libx264 -b:v 1M <output>ffmpeg -i <input> -c:v libx265 -b:v 1M <output>ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M <output>

Avoid using this mode! One of the main x264 developers himself says you should never use it. Why? As the encoder doesn’t know exactly what’s ahead in time, it will have to guess how to reach that bitrate. This means that the rate itself will vary, especially at the beginning of the clip, and at some point reach the target. Especially for HAS-type streaming, this leads to huge quality variations within short segments.

This is not a constant bitrate mode! While ABR is technically a VBR mode, it’s not much better than specifying a constant bitrate, in that it doesn’t reliably deliver good quality.

Good for: Quick (and dirty) encodes
Bad for: Almost anything

2，Average Bitrate(ABR)：平均码率模式

ffmpeg使用: ffmpeg -i <input> -c:v libx264 -b:v 1M <output>

避免使用此模式!一个主要的x264开发人员自己说，你不应该使用它。为什么?由于编码器不知道确切的前方时间，它将不得不猜测如何达到该比特率。这意味着速率本身会发生变化，特别是在剪辑开始的时候，在某一时刻达到目标。特别是HAS-type的流媒体，这导致巨大的质量差异在短片段。

这不是一个恒定比特率模式!虽然ABR在技术上是一种VBR模式，但它并不比指定恒定的比特率好多少，因为它不能可靠地提供良好的质量。

Good for: Quick and dirty encodes 快速和下流的编码
Bad for: Almost anything 大部分场景下是不好的

Constant Bitrate (CBR)

If it is a requirement for your use case, you can force the encoder to always use a certain bitrate. The bitrate will always be (roughly) the same, even if it is not needed. You can enable it for x264 by setting the nal-hrd option:

ffmpeg -i <input> -c:v libx264 -x264-params "nal-hrd=cbr:force-cfr=1" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M <output>

The output file needs to be .ts (MPEG-2 TS), since MP4 does not support NAL stuffing. Note that this mode will waste bandwidth if your source is easy to encode, but it ensures that the bitrate stays constant over your entire stream. You will find some more notes here. Use of this mode may make sense in some applications, but you generally want to allow streams to use a lower bitrate when possible.

For VP9, you need this:

ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -maxrate 1M -minrate 1M <output>

Good for: Keeping a constant bitrate (duh); video streaming (e.g. Twitch)
Bad for: Archival; efficient use of bandwith

3，Constant Bitrate(CBR):固定码率模式

ffmpeg使用(通过启用nal-hrd选项强制编码器始终使用特定的比特率)

ffmpeg -i <input> -c:v libx264 -x264-params "nal-hrd=cbr:force-cfr=1" -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M <output>

这种模式下输出文件需要指定为ts格式，因为mp4格式不支持NAL stuffing（填充）。

注意:这种模式下，会比较浪费带宽，如果你的视频源是比较容易编码的那种的话，但它可以确保比特率在整个流中保持不变。在某些应用程序中使用这种模式可能有意义，但是您通常希望允许流在可能的情况下使用较低的比特率。

Good for: Keeping a constant bitrate (duh); video streaming (e.g. Twitch)

Bad for: Archival; efficient use of bandwith

好处：在保持恒大的比特率和视频流(例如twitch)场景有利

坏处：在存储和高效利用带宽的场景下是不利的。

2-Pass Average Bitrate (2-Pass ABR)

Allowing the encoder to do two passes (or more) makes it possible for it to estimate what’s ahead in time. It can calculate the cost of encoding a frame in the first pass and then, in the second pass, more efficiently use the bits available. This ensures that the output quality is the best under a certain bitrate constraint. It will also mean that the bitrate will vary a bit over time, which is why this mode can also be called Variable Bitrate (VBR), although this is a bit of an ambiguous term.

Enable it for x264 with:

ffmpeg -i <input> -c:v libx264 -b:v 1M -pass 1 -f null /dev/nullffmpeg -i <input> -c:v libx264 -b:v 1M -pass 2 <output>.mp4

For x265, replace libx264 with libx265 and set the pass option in the private options field:

ffmpeg -i <input> -c:v libx265 -b:v 1M -x265-params pass=1 -f null /dev/nullffmpeg -i <input> -c:v libx265 -b:v 1M -x265-params pass=2 <output>.mp4

For VP9, it’s like for x264:

ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -pass 1 -f null /dev/nullffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -pass 2 <output>.webm

This is the easiest way to encode a file for streaming. With two caveats: You don’t know what the resulting quality will be, so you will have to do some tests to make sure that your bitrate is actually high enough for some complex contents. Another downside of this mode is that there may be local spikes in bitrate, meaning you may send more than your client can receive. As for choosing bitrates, YouTube gives you recommendations on settings for uploads, but keep in mind that those are optimized for having you upload good quality, so in practice you can choose lower bitrates, too.

Good for: Reaching a certain target bitrate; encoding for devices
Bad for: If you need quick encoding (e.g., live streaming)

4，2-Pass Average Bitrate(2-Pass ABR)：2-Pass平均码率模式

ffmpeg使用: ffmpeg -i <input> -c:v libx264 -b:v 1M -pass 2 <output>.mp4

允许编码器进行两次(或两次以上)传递，使其能够及时估计前方的情况。它可以在第一轮计算编码帧的成本，然后在第二轮更有效地利用可用的比特。这确保了在一定的比特率约束下，输出质量是最好的。

这是对文件进行流编码的最简单方法。有两点需要注意:你不知道结果的质量如何，所以你必须做一些测试来确保你的比特率对于一些复杂的内容来说是足够高的。这种模式的另一个缺点是可能会出现本地比特率峰值，这意味着您发送的比特率可能会超过您的客户端能够接收到的比特率。至于选择比特率，YouTube会给你推荐上传的设置，但要记住，这些设置是为了让你上传的质量更好而优化的，所以实际上你也可以选择更低的比特率。

Good for: Reaching a certain target bitrate; encoding for devices
Bad for: If you need quick encoding (e.g., live streaming)

好处是对于一些需要达到一定比特率的场景或者编码设备是有利的。

而对于实时流或者直播这个是不利的。

youtube比特率选择的参考链接：

https://support.google.com/youtube/answer/1722171?hl=en

如下：

Constant Quality (CQ) / Constant Rate Factor (CRF)

I’ve talked about the Constant Rate Factor in another article in more detail. It basically gives you constant quality throughout your encoding process. It’s a “set and forget” thing—just specify the CRF and let the encoder do the rest.

ffmpeg -i <input> -c:v libx264 -crf 23 <output>ffmpeg -i <input> -c:v libx265 -crf 28 <output>ffmpeg -i <input> -c:v libvpx-vp9 -crf 30 -b:v 0 <output>

In H.264 and H.265, CRF ranges from 0 to 51 (like the QP). 23 is a good default for x264, and 28 is the default for x265. 18 (or 24 for x265) should be visually transparent; anything lower will probably just waste file size. Values of ±6 will result in about half or twice the original bitrate. For VP9, the CRF can be from 0 to 63. Recommended values are from 15–35.

The only downside with this mode is that you don’t know what the resulting file size or the fluctuation of the bitrate will be.

Note that a two-pass and CRF encode with the same resulting bitrates should be identical in quality. The main difference is that with two-pass, you can control the file size (if that is a requirement), whereas with CRF you just specify the quality you want.

Good for: Archival; achieving the best possible quality
Bad for: Streaming; obtaining a certain bitrate / file size

5，Constant Quality(CQ)/Constant Rate Factor(CRF):恒定质量或者恒定速率因子模式

ffmpeg示例:

ffmpeg -i <input> -c:v libx264 -crf 23 <output>

在H.264和H.265中，CRF的范围是从0到51(就像QP)。23是x264的良好默认值，28是x265的默认值。18 (x265为24)应该在视觉上透明;任何更低的值都可能会浪费文件大小。±6的值将导致大约一半或两倍的原始比特率。对于VP9, CRF可以是0到63。推荐值为15-35。
这种模式唯一的缺点是，您不知道最终的文件大小或比特率的波动。
请注意，双通道和CRF编码具有相同的比特率应该是相同的定性。

Good for: Archival; achieving the best possible quality
Bad for: Streaming; obtaining a certain bitrate / file size

对于存储归档模式，这种是有利的，能实现最好的视频质量。而对于流来说，或者获得一定码率或者文件体积的来说，这种是不利的。

Constrained Encoding (VBV)

The Video Buffering Verifier provides a way to ensure that the bitrate is constrained to a certain maximum. This is useful for streaming, as you can now be certain that you won’t send more bits than you promised within a certain time frame. VBV can be used both with 2-pass VBR (use it in both passes), or with CRF encoding—it can be “added” to the already presented rate control modes. The latter mode is also called “capped CRF”.

Turn on VBV with the -maxrate and -bufsize options to set the maximum bitrate and the expected client buffer size:

ffmpeg -i <input> -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M <output>ffmpeg -i <input> -c:v libx265 -crf 28 -x265-params vbv-maxrate=1000:vbv-bufsize=2000 <output>

VP9 has a similar mode, not called VBV, but with the same idea behind it:

ffmpeg -i <input> -c:v libvpx-vp9 -crf 30 -b:v 2M <output>

Note: If you do this for a live streaming application and you want to speed up the encoding process, with x264 and x265 you can add the -tune zerolatency and -preset ultrafast options. They reduce the quality you get for a certain bitrate (i.e., compression efficiency), but significantly speed up the process. For libvpx-vp9, you want to set -quality realtime and -speed 5. See the H.264 and VP9 guides for more info.

To use this approach with constrained ABR-VBV encoding:

ffmpeg -i <input> -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f null /dev/nullffmpeg -i <input> -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 2 <output>

For x265:

ffmpeg -i <input> -c:v libx265 -b:v 1M -x265-params pass=1:vbv-maxrate=1000:vbv-bufsize=2000 -f null /dev/nullffmpeg -i <input> -c:v libx265 -b:v 1M -x265-params pass=2:vbv-maxrate=1000:vbv-bufsize=2000 <output>

For VP9:

ffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f null /dev/nullffmpeg -i <input> -c:v libvpx-vp9 -b:v 1M -maxrate 1M -bufsize 2M -pass 2 <output>

Note: Here a one-pass approach can also be used, which—according to the x264 developer—is often as good as two passes, but it won’t compress the clip as efficiently.

How should you set the bufsize? This depends on how much variability you want in the bitrate. A good default is to have the buffer size be twice as large as the maximum rate, but suggestions may vary depending on the streaming setup. If your client buffer is smaller (in the order of just a few seconds), your bufsize should be around the same size as the maxrate. If you want to constrain your stream’s bitrate, try setting bufsize to half of the maximum rate or less.

When you apply VBV to CRF encoding, the trick is to find a CRF value that, on average, results in your desired maximum bitrate, but not more. If your encode always “maxes out” your maximum bitrate, your CRF was probably set too low. In such a case the encoder tries to spend bits it doesn’t have. On the other hand, if you have a high CRF that makes the bitrate not always hit the maximum, you could still lower it to gain some quality. For example, you encode at CRF 18 without VBV. Your clip ends up with an average bitrate of 3.0 Mbit/s. But your want your VBV setting to cap the clip at 1.5 Mbit/s, so you need to lower your CRF to about 24 to only get half the bitrate.

Good for: Streaming under bandwith constraints; live streaming (with CRF, 1-pass); VoD streaming (with target bitrate, 2-pass)
Bad for: People who want to play around; archival

6，Constrained Encoding(VBV)：约束编码模式VBV

VBV视频缓冲验证器提供了一种确保比特率被限制到某个最大值的方法。这对于流媒体非常有用，因为您现在可以确定在一定的时间范围内不会发送比承诺的更多的比特。VBV既可以与2-Pass VBR一起使用(在两个通道中都使用)，也可以与CRF编码一起使用——它可以“添加”到已经提供的速率控制模式中。后一种模式也称为“上限CRF”。

打开VBV的-maxrate和-bufsize选项来设置最大比特率和预期的客户端缓冲区大小。

ffmpeg示例：

ffmpeg -i <input> -c:v libx264 -crf 23 -maxrate 1M -bufsize 2M <output>

ffmpeg -i <input> -c:v libx265 -crf 28 -x265-params vbv-maxrate=1000:vbv-bufsize=2000 <output>

ffmpeg -i <input> -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 1 -f null /dev/null

ffmpeg -i <input> -c:v libx264 -b:v 1M -maxrate 1M -bufsize 2M -pass 2 <output>

注意:如果您对直播应用程序这样做，并且希望加快编码过程，那么使用x264和x265的时候，可以添加-tune zerolatency和- ultrafast选项。他们降低了你得到一定比特率的质量，但大大加快了过程。对于libvpx-vp9，需要设置-quality realtime和-speed 5。有关更多信息，请参阅H.264和VP9指南。

如何设置bufsize?这取决于你希望比特率有多大的可变性。一个好的默认设置是将缓冲区大小设置为最大速率的两倍，但是建议根据流设置的不同而有所不同。如果您的客户端缓冲区更小(大约几秒钟)，则bufsize应该与maxrate大小相同。如果您想约束流的比特率，请尝试将bufsize设置为最大比特率的一半或更少。

当您将VBV应用于CRF编码时，诀窍是找到一个CRF值，该值平均会产生您所期望的最大比特率，但不会更多。如果你的编码总是“最大化”你的最大比特率，你的CRF可能设置得太低了。在这种情况下，编码器试图花费它没有的比特。另一方面，如果你有一个高的CRF，使比特率不总是达到最大，你仍然可以降低它来获得一些质量。例如，你编码在crf18没有VBV。您的剪辑以3.0 Mbit/s的平均比特率结束。但你希望你的VBV设置上限剪辑1.5 Mbit/s，所以你需要把你的CRF降低到24来得到一半的比特率。

Good for: Streaming under bandwith constraints; live streaming (with CRF, 1-pass); VoD streaming (with target bitrate, 2-pass)
Bad for: People who want to play around; archival

这个模式对于在一定受限的带宽流媒体下和直播流(用crf,1-pass模式)，;VoD流媒体(使用目标比特率，2-pass)场景，是有好处的，而对于归档存储场景，并不是那么有利。

Comparison Example

Here’s a quick comparison between the different rate control algorithmns. I took the free Big Buck Bunny and Tears of Steel video sequences and selected three different parts (of 30 seconds length) each. Note that these sequences are uncompressed, raw footage. The videos were then encoded with libx264 and its default settings. The only thing that was varied was the different rate control modes. I set different target bitrates (750, 1500, 3000, 7500 kbit/s) and maximum rates (for VBV) and QP/CRF values (17, 23, 29, 35). You can find the scripts used for the comparison on GitHub.

Note that this comparison is by no means exhaustive or fully representative. Typically you want to try many different sequences of various genres as well as different encoders. I am planning to update these tests in the near future. Still, these tests should give you an idea on what the different modes do.

Let’s start with the different bitrate control modes. The left column is for 3000 kbit/s, the right for 7500 kbit/s. I excluded the other target bitrates since they did not show strong differences in the graphs, since the bitrate is already at such a low point that the encoder does not have a lot of choices on how to assign it. The rows are the different clips from Big Buck Bunny (BBB) and Tears of Steel (ToS). The line represents a LOESS smoothing over the individual frame sizes—it’s an indication of how the bitrate changes over the clip’s duration.

7，实例比较演示

让我们从不同的比特率控制模式开始。左边是3000 kbit/s，右边是7500 kbit/s。我排除了其他目标比特率，因为它们在图中没有表现出强烈的差异，因为比特率已经处于如此低的水平，编码器在如何分配它上没有太多的选择。这些行是不同的剪辑从大巴克兔(BBB)和眼泪的钢铁(ToS)。这条线代表了对单个帧大小的LOESS(拟合)平滑——它指示了比特率在剪辑持续时间内的变化。

You can see that—especially for the first four contents—ABR (the turquoise line) and ABR+VBV (purple) wrongly estimate the clip’s complexity. In fact, the Big Buck Bunny sequence starts with a fade-in, smooth gradients and low motion, which means that not many bits are needed to compress it with good enough quality. The 2-pass approach correctly starts with a lower bitrate and saves bandwith. The last third of the video clip contains lots of spatial details, which makes the 2-pass mode use up more of the bits that it saved in the beginning.

For the second Big Buck Bunny clip, the different encoding modes actually align better than expected, although again it is visible how 2-pass causes a more extreme variation in bitrate than with the other modes.

Of course, there are also clips that are so easy to encode (or that have little variation in complexity). Here, the rate control modes do not differ that much.

For the quality-based modes (CQP and CRF), I only show the results from CRF/QP 17 and 23, which are at the “good” end of the quality range (just like 3000 and 7500 kbit/s are “good” values for full HD video). The order of the curves is inversed—lower means better quality:

你可以看到——尤其是前四个内容——ABR(绿松石线)和ABR+VBV(紫色)错误地估计了剪辑的复杂性。事实上，大的巴克兔序列以渐隐、平滑的梯度和低运动开始，这意味着不需要很多位元来压缩它以获得足够好的质量。2-pass方法正确地以较低的比特率开始，并节省带宽。视频剪辑的最后三分之一包含了大量的空间细节，这使得2-pass模式消耗了更多它在开始时保存的比特。

对于基于质量的模式(CQP和CRF)，我只显示CRF/QP 17和23的结果，这是质量范围的“好”端(就像3000和7500 kbit/s是全高清视频的“好”值)。曲线的顺序是相反的——越低意味着质量越好:

Here, the same trends as for 2-pass can be seen: the bitrate follows the content complexity. However, with CRF, it is more constrained, saving bits where they are not needed. The most interesting case is the bottom left: CRF saves bitrate over constant QP, as it usually does, but it does so in a constant offset. I would have to guess why this is the case—maybe this post will be updated with some further analyses.

Generally we can see how a CRF approach would nicely match the content, if only we could know beforehand what the resulting average bitrate would be… This is where CRF+VBV comes into play:

在这里，可以看到与2-pass相同的趋势:比特率跟随内容的复杂性。然而，使用CRF时，它受到了更多的限制，可以在不需要的地方保存数据。最有趣的情况是左下角:CRF比常数QP节省比特率，就像它通常做的那样，但它是以常数偏移量做到的。我不得不猜测为什么会这样，也许这篇文章将会更新一些进一步的分析。

一般来说，我们可以看到CRF方法如何很好地匹配内容，只要我们事先知道结果的平均比特率是多少……这就是CRF+VBV发挥作用的地方:

Choosing the correct target / maximum bitrate for a given CRF is often guesswork and depends entirely on the source video. However, when correctly done, you will not constrain the quality too much, pushing it to the limit (as in the case with 3000 kbit/s and CRF 17). You also don’t want to let the bitrate vary too much. CRF 23 is the default setting for libx264, and you can see that given a proper target bitrate setting (like 7500 kbit/s), this encoding mode would let the bitrate vary enough to account for differences in content complexity, still retaining compliance to the VBV model.

为给定的CRF选择正确的目标/最大比特率通常是猜测，完全取决于源视频。然而，当正确完成时，您不会对质量进行太多的限制，将其推到极限(如3000 kbit/s和CRF 17的情况)。你也不想让比特率变化太多。CRF 23是libx264的默认设置，您可以看到，在给定适当的目标比特率设置(比如7500 kbit/s)的情况下，这种编码模式允许比特率的变化足以反映内容复杂性的差异，同时仍然符合VBV模型。

Wrap-Up

Making sense of the different rate control modes isn’t easy. Unfortunately, the most simple solution (just specifying bitrate) is one that isn’t recommended at all, but the Web keeps propagating code examples using this method.

To summarize, here’s what you should do, depending on your use case:

Archival — CRF that gives you the quality you want.
Streaming — Two-pass CRF or ABR with VBV-constained bitrate.
Live Streaming — One-pass CRF or ABR with VBV-constained bitrate, or CBR if you can waste bits.
Encoding for Devices — Two-pass ABR, typically.

Some more reading material:

8，小结

理解不同的速率控制模式并不容易。不幸的是，最简单的解决方案(只指定比特率)是完全不推荐的，但是Web一直使用这种方法传播代码示例。

总结一下，根据你的用例，你应该这样做:

档案- CRF，给你想要的质量。
流-2-pass(双通道)CRF或ABR与vbv恒定的比特率。
实时流媒体-一遍CRF或ABR与vbv恒定的比特率，或CBR，如果你可以浪费比特。
设备编码——通常是2-pass ABR。

转载请注明出处：https://www.cnblogs.com/lihaiping/p/11726306.html

理解码率控制模式(x264,x265,vpx)