📚 课程目录第4章 CBR模式详解

4、CBR模式详解：恒定码率的实现原理，在高通平台上的配置方法，适用场景

聊到码率控制，CBR（恒定码率）是绕不开的基础模式。很多刚入行的朋友觉得CBR很简单——不就是把码率设死吗？其实没那么简单。我最早接触CBR是在做视频通话项目，那时候被码率波动折腾得够呛，才真正理解了什么叫“恒定”。

4.1 CBR的核心原理

CBR的目标很明确：输出码率尽量接近目标值，波动范围控制在±5%以内。但视频内容本身是变化的——静态画面信息量小，运动场景信息量大。要让码率恒定，就得动态调整量化参数QP。

说白了，CBR是一个闭环反馈系统：

编码器统计已输出比特数
对比目标码率，计算偏差
根据偏差调整后续帧的QP
QP变化影响编码比特数
循环往复，维持码率稳定

关键公式（简化版）：

目标比特/帧 = 目标码率 / 帧率

QP调整量 = f(实际比特 - 目标比特)

其中f是反馈函数，高通平台通常使用PID控制器

这里有个容易忽略的点：CBR不是每帧都输出相同比特数，而是长时间平均码率趋近目标。短时间内的比特波动是允许的，但缓冲区会平滑掉这些波动。

4.2 高通平台CBR配置方法

在高通Camera HAL中，CBR配置主要在vendor/qcom/proprietary/mm-camera路径下。我习惯通过chromatix XML文件来配置，这样不用重新编译整个HAL。

配置入口通常有三个层级：

层级	配置文件	作用范围
Sensor级别	`sensor_xxx_chromatix.xml`	特定sensor的编码参数
Usecase级别	`usecase_xxx.xml`	特定场景（如录像、视频通话）
Stream级别	`stream_xxx.xml`	特定码流（如主码流、子码流）

具体配置代码示例：

<!-- chromatix XML中CBR配置片段 -->
<rate_control>
    <rc_mode>CBR</rc_mode>
    <target_bitrate>20000000</target_bitrate> <!-- 20Mbps -->
    <max_bitrate>21000000</max_bitrate>     <!-- 最大允许比特率 -->
    <min_bitrate>19000000</min_bitrate>     <!-- 最小允许比特率 -->
    <hrd_conformance>true</hrd_conformance> <!-- 开启HRD兼容 -->
    <cpb_size>40000000</cpb_size>           <!-- CPB缓冲区大小 -->
</rate_control>

我的经验：CPB（编码图像缓冲区）大小很关键。设太小会导致码率波动时频繁丢帧，设太大会增加延迟。视频通话场景我一般设为目标码率的2倍，录像场景可以设到3-4倍。

4.3 CBR的PID参数调优

高通平台的CBR核心是PID控制器。三个参数各有分工：

Kp（比例系数）： 响应当前码率偏差，调大能快速收敛，但容易过冲
Ki（积分系数）： 消除稳态误差，解决长期码率偏移问题
Kd（微分系数）： 抑制码率突变，让QP变化更平滑

我曾经在一个4K录像项目上，默认PID参数导致码率波动达到±15%。后来花了三天调参，最终把波动压到了±3%以内。调参口诀我总结为：

CBR调参三步法：

先调Kp，让码率能快速跟踪目标值
再加Ki，消除长期偏移（注意Ki过大会引起低频振荡）
最后加Kd，平滑QP变化曲线

4.4 CBR的适用场景分析

不是所有场景都适合CBR。我根据实际项目经验，整理了适用性矩阵：

场景	推荐模式	原因
视频通话/直播	CBR	带宽固定，需要稳定码率防止卡顿
视频监控存储	CBR	存储空间有限，需要精确控制文件大小
广电/流媒体推送	CBR	传输信道带宽固定，码率波动会导致丢包
本地录像（高质量）	VBR/CQP	存储空间充足，追求画质优先
慢动作/高帧率	VBR	场景复杂度变化大，CBR会严重损伤画质

避坑指南：我曾经在一个慢动作录像项目上用了CBR，结果运动场景画质惨不忍睹——码率被限制死了，QP被迫拉高，块效应非常明显。后来换成VBR，画质问题迎刃而解。记住：CBR牺牲画质换码率稳定，VBR牺牲码率稳定换画质。

4.5 CBR的典型问题与解决方案

做CBR配置时，有几个坑我踩过，分享给大家：

码率过冲： 场景切换时（如从暗场切到亮场），QP来不及调整，码率瞬间飙升。解决方案是开启scene_change_detection，在场景切换时强制重置PID积分项。
低码率下的画质崩溃： 目标码率太低时，CBR会强制压缩，导致画面模糊。我建议设置min_qp下限，避免QP无限增大。
帧率波动影响： 实际帧率低于目标帧率时，CBR会误判为码率不足，继续降低QP。需要开启frame_rate_adaptive，让码率控制感知实际帧率。

4.6 CBR与HRD兼容性

做视频通话或直播时，HRD（假想参考解码器）兼容性很重要。高通平台默认支持HRD，但需要正确配置：

<!-- HRD配置示例 -->
<hrd>
    <cpb_size>40000000</cpb_size>
    <dpb_size>40000000</dpb_size>
    <initial_cpb_removal_delay>500</initial_cpb_removal_delay>
    <initial_cpb_removal_delay_offset>0</initial_cpb_removal_delay_offset>
</hrd>

这里initial_cpb_removal_delay的单位是90kHz时钟周期，500对应约5.5ms。这个值设太小会导致解码器缓冲区上溢，设太大会增加端到端延迟。

我的建议：做视频通话时，CPB大小设为目标码率的1.5-2倍，延迟敏感场景可以再小一点。但不要小于1倍，否则码率波动时很容易触发丢帧保护。

4.7 CBR的调试与验证

配置完成后，怎么验证CBR是否正常工作？我一般用以下方法：

抓取码流分析： 用adb pull拉取编码后的H.264/H.265码流，用ffprobe或bitrate_viewer查看码率曲线
实时监控： 高通平台支持mm-camera-test工具，可以实时打印每帧的比特数和QP值
长时间稳定性测试： 录制30分钟以上视频，检查码率是否持续稳定在目标值附近

我习惯写一个自动化脚本，每帧记录frame_size和qp_avg，然后绘制曲线。如果码率曲线在场景切换时有明显尖峰，说明PID参数还需要微调。

这张图展示了CBR的完整闭环流程。从目标码率设定开始，经过PID控制器计算QP调整量，编码器按新QP编码，最后统计实际码率反馈回PID控制器。这个循环每帧都在执行，频率取决于帧率。