Intel 核显几种速率控制方式的比较
obs直播软件里qsv的速率控制方式有：CBR、VBR、VCM、CQP、AVBR、ICQ、LA-ICQ、LA，而x264的码率控制方式仅有CBR、ABR、VBR、CRF四种，极客湾也进行过介绍（https://www.bilibili.com/video/av37424012），这里大致翻译了一下Intel开发者社区里的一篇文章（在Google翻译的基础上进行一些微调，原文地址：https://software.intel.com/zh-cn/articles/common-bitrate-control-methods-in-intel-media-sdk）。
英特尔®MediaSDK中的比特率控制方法（BRC）
由Surbhi M.发布于2014年8月19日，更新于2016年5月2日
介绍
想要通过 IntelMedia®SDK 或 Intel®MediaServer Studio中 的相同组件提高编码质量？ 有两个主要的方式：
编码器算法/参数（包括“宏”算法调整复杂性权衡，如质量预设/目标使用）
比特率控制
Intel Media SDK提供了许多方法来设置比特率控制以满足您的需求。
可用的比特率控制算法
英特尔编码器包括多种类型的比特率控制，每种控制都针对不同类型的用例而设计。 没有通用的选择在所有场景中都是最佳选择。 选择最符合您要求的模式（适用于AVC编解码器）：
建议 ：
Lookahead（LA）通常是编码为长期目标比特率，并且单个帧延迟不是首要关注点时，最佳画质的选择 - 例如，文件转码。
CBR是稳定比特率和低延迟的最佳通用选项，VCM也可能是某些视频会议案例的理想选择。
对于游戏/显示流媒体，最佳选择是QVBR，它提供最佳的主观视频质量与网络要求的帧大小容差。
x264的默认速率控制（FFmpeg的默认h264方式）是CRF。 这允许比特率波动以维持目标质量水平。 Media SDK的ICQ和LA_ICQ是这类算法的最佳匹配。
测量比特率的困难
与未压缩视频不同，编码比特流的帧大小预计会有很大差异。 IDR和I帧可以比伴随的P帧和B帧大一个数量级或更大。 这是视频压缩的核心思想之一：P帧和B帧存储差异，不对整个图像进行编码。 B帧往往小于P帧。 内容差异/场景变化可能导致进一步的变化。 此外，存在分层B帧，其提供良好的有效压缩效率并限制误差的传播，就尺寸方面而言，这些帧更接近P帧。
HRD / VBV合规性
假设参考解码器（HRD），以前称为来自mpeg2时代的视频缓冲验证器（VBV），是“漏桶”模型，如果比特流符合，则增加任何符合解码器将能够接收流的可能性。按预期没有延迟或丢帧。 如果编码流的目标受众包括低成本硬件解码器而没有用于通用计算机的大多数处理器可用的额外缓冲+错误恢复，则这尤其必要。
HRD是一种简化模型，假设数据是根据各个帧大小到达但以给定比特率退出。 目标是保持缓冲区或“桶”不受下溢或上溢的影响。
当输入数据帧不像HRD的指定退出速率那样快地提供新数据时，发生下溢（缓冲区空）。
当缓冲区的退出速率不足以在新帧到达时吸收新帧时，会发生上溢（缓冲区超出满）。
对于具有小缓冲区的硬件解码器，上溢和下溢可能意味着丢帧和其他不良的最终用户体验。 但是，保持HRD一致性可能很昂贵。 例如，在某些情况下，必须重新编码帧。 它还会增加BRC算法的复杂性和性能影响。 因此，最好先了解何时需要。
BRC算法的类型
专家算法
恒定QP（CQP）提供最大的控制和最佳性能。 毫无疑问，使用英特尔编解码器可以通过CQP和自定义内容分析获得最佳编码效率。 CQP通常也具有显着的性能优势。 CQP最接近参考实现。 它是访问编解码器功能和测量编码器参数/算法权衡效果的最直接方式，也是评估其他编解码器算法实现的最明确方法。
毫无疑问：如果没有额外的开发，这项工作就无法完成。 简单地为所有帧设置一个全局QP而不进行内容分析/动态调整很可能比其他BRC替代品具有更低的比特率和质量。 CQP的主要缺点是它完全取决于应用程序的量化器选择。 由于QP与感知质量或结果比特率之间没有简单或线性映射，因此必须建立一个反馈系统来分析内容并适应每个帧大小的结果。
然而，CQP模式解锁了最复杂的内容分析类型，它提供了广泛的创新领域，利用计算机视觉和感知敏感内容分析，跨帧和使用每MB QP调整。
缺乏分析意味着CQP通常是最快（最低复杂度）的BRC方法，尽管应用程序级别所需的额外工作通常会超过这个。 由于CQP最好留给专家用户，本文的其余部分将重点关注“自动”BRC算法。
遗留算法
从音频和视频压缩开始的标准/传统算法是CBR和VBR：
恒定比特率（CBR）
在该方法中，当比特流帧的大小小于满足HRD要求所需的大小时，编码器执行填充（将零添加到编码帧的末尾）。 CBR“优化”恒定的数据流，这意味着总体比特率的很大一部分被浪费在填充上而不是用于编码帧细节。 CBR的目标是提供恒定的数据流，这主要导致未使用的容量。 此方法可用于历史/遗留原因 。 这是许多Media SDK示例中使用的默认BRC方法。
BufferSizeInKB是CBR的重要参数。 较小的BufferSizeInKB意味着较小的帧大小变化。 在非常小的缓冲区大小下，维护HRD变得越来越困难，但这是降低CBR峰值的最佳方法。 较大的缓冲区意味着可以允许更多变化以在需要时保持质量。 一个这样的例子是使用教程来更改缓冲区inKB以查看瞬时比特率的变化。
这里以Kbps使用的比特率表示在被编码的帧的周期内的变化。 可编码为4000kbps（目标比特率）的最小缓冲区大小为34KB，低于此编码器会抛出错误。 在该变化开始变得饱和之后，瞬时比特率的变化从34KB到1000KB。 可以看到最小的变化，缓冲区大小等于200KB。 但是，如果可以容忍大的变化，那么其他BRC模式可能更合适。 对于不同的输入，该值将是不同的，并且对于不同比特率的编码也将是不同的。
可变比特率（VBR）
该方法允许更多比特率变化以匹配输入的复杂性，即将更高比特率分配给诸如场景改变和低比特率到更复杂场景的复杂场景。 它试图实现 更小的整体文件大小，但也会产生不可预测的峰值。 该方法通过允许比特率更多地波动并且还通过禁用填充来提供总体更好的比特率质量。 这是Media SDK教程中使用的默认方法。 但是，对于需要低延迟且必须保持目标比特率的情况子集，应考虑VBR。
使用Media SDK教程运行比较VBR和CBR的测试。
前瞻算法
Lookahead是VBR的扩展，代表了英特尔编解码器自动BRC的重大进步。 它可以提供大量的质量改进，有时这种改进比选择更的目标使用率更大，与CBR / VBR的FPS /信道容量大致相同。 它应被视为许多文件到文件转码方案的默认选择。
Lookahead为关键的VBR / CBR挑战提供了答案：可以预见到像I帧和场景变化这样的大帧大小变化的原因。 分析帧的缓冲区（长度可配置前瞻深度参数）以查找潜在的比特率中断。 这允许具有两遍编码的许多优点的“预览”或“前瞻”。 实际上，具有提前通知，更高的可变性和更长的延迟的VBR。
它的工作原理是在实际编码之前对包括复杂性，相对运动和依赖性在内的数十个帧进行广泛分析。 它在帧之间分配可用的比特预算，以产生最佳的编码质量。 它在快速运动视频和计算机动画上产生了良好的效果。 此外，还改进了SSIM，PSNR和主观视频质量等客观指标。 它适用于任何GOP模式，但B帧的存在提供了最佳质量增益。 一个副作用是它显着增加编码延迟和内存消耗。 对于这种增加的延迟，它可能不是游戏直播的最佳选择。
LookAheadDepth ，一个指定超前速率控制算法深度的参数。 它是编码前分析的帧数。 有效值范围为10到100.要指示SDK编码器使用默认值，应用程序应将此字段归零。 此模式中唯一可用的速率控制参数是mfxInfoMFX :: TargetKbps。 其他两个参数MaxKbps和InitialDelayInKB将被忽略。 必须初始化Media SDK以使用API版本1.7或更高版本才能使用Media SDK方法。
Lookahead仅适用于英特尔®Iris™Pro图形，英特尔®Iris™图形和Haswell架构（第四代核心版）上的英特尔®高清显卡以及前向。 支持隔行扫描和渐进式内容。
特殊用途算法
ICQ / LA_ICQ ：这些算法专注于维持目标质量水平（大致相当于CBR 1-51量化）。 它们允许比CBR / VBR / lookahead更大的变化。
ICQ（智能CQ）模式保持给定的质量水平
LA_ICQ为算法添加了超前缓冲区
QVBR：还通过mfxCodingOption3设置目标质量等级，QVBRQuality参数，以及可能需要限制可变性的场景的目标比特率，例如游戏/显示流场景。 该算法试图以最少的比特来实现主观质量，同时尝试保持比特率恒定并且遵循HRD合规性。 QVBR从第4代Intel®Core处理器（代号Haswell）开始支持。
VCM ：这是一种专门的视频会议模式。 在某些视频会议场景中，它可以在较低的比特率下提供更高的质量。
注意 ：对于AVC编解码器，Look Ahead（LA），LA_ICQ，LA_HRD，VCM，QVBR在软件实现中不可用。 有关最新更新和详细信息，请查看发行说明 。
其他参数
BRCParamMultiplier ，一个参数，指定比特率控制参数的乘数。 实现更高的比特率是有用的。 该乘法器与TargetKbps目标比特率（mfxU16）相乘，可实现相当高的比特率（经过验证，最高可达200mbps）。 请记住，此乘数也会影响BufferSizeInKB，IntialDelayInKB和MaxKbps。 下表显示了使用此参数时的方案。
我使用了simple_encode教程（取自Media Solution Portal上的教程）对720p - Park Joy无压缩视频进行编码，以便通过BRCParamMultiplier和没有BRCParamMultiplier实现更高的比特率，结果如下：
该表显示在60Mbps之后，传统方法没有达到更高的比特率。 在这些情况下，建议您使用BRCParamMultipler超过60Mbps，并确保相应地修改Maxlength和BufferSizeInKB。 BRCParamMultiplier是在Media SDK API 1.3版本中引入的。
