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

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

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

翻译：lihaiping1603@aliyun.com

 

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

 

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

 

你的编码场景是什么？

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

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

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

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

 

码率控制模式

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

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

 

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    大部分场景下是很差的

 

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)场景有利

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

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

以下：

 

 

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

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

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)场景，是有好处的，而对于归档存储场景，并非那么有利。

 

7，实例比较演示

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

 

 

 

 

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

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

 

 

 

 

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

通常来讲，咱们能够看到CRF方法如何很好地匹配内容，只要咱们事先知道结果的平均比特率是多少……这就是CRF+VBV发挥做用的地方:

 

 

 

 

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

 

8，小结

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

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

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

 

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