4、码率控制：CBR/VBR/CRF模式详解、目标码率设置、码率波动控制
码率控制，说白了就是决定「每一帧该分配多少比特」。你想想看，网络带宽是有限的，编码器不能想用多少就用多少。我刚开始做WebRTC的时候，以为只要设个码率就完事了，结果视频卡得不行。后来才明白，码率控制模式选错了，后面所有参数都是白搭。
这一章，咱们把CBR、VBR、CRF这三种模式掰开揉碎讲清楚。顺便聊聊目标码率怎么设，码率波动怎么压住。
4.1 三种码率控制模式
WebRTC里常用的码率控制模式就三种：CBR、VBR、CRF。它们的目标完全不同，适用场景也天差地别。
| 模式 | 全称 | 核心目标 | 码率波动 | 画质稳定性 |
|---|---|---|---|---|
| CBR | Constant Bitrate | 码率恒定 | 极小 | 较差（运动场景画质下降） |
| VBR | Variable Bitrate | 画质优先 | 较大 | 较好 |
| CRF | Constant Rate Factor | 感知画质恒定 | 不确定 | 最好 |
4.1.1 CBR（恒定码率）
CBR要求编码器输出的码率始终围绕目标值波动，波动范围通常控制在±5%以内。WebRTC的实时通信场景，默认就是CBR模式。为什么？因为网络拥塞控制算法需要可预测的码率输出。
我个人习惯在弱网场景下强制使用CBR。举个例子，我在项目中遇到过用户用4G网络开视频会议，信号时好时坏。如果码率忽高忽低，网络模块根本来不及反应，直接导致丢包和卡顿。CBR至少保证了「发送量」是可控的。
CBR的代价也很明显：运动剧烈的画面，编码器为了压住码率，只能降低量化参数QP，画质会明显下降。说白了，CBR是用画质换稳定性。
核心要点：CBR适用于带宽受限且需要稳定码率的场景，如WebRTC实时通信、直播推流。但不要期望它在运动场景下保持高画质。
4.1.2 VBR（可变码率）
VBR允许码率根据画面复杂度动态变化。简单场景码率低，复杂场景码率高。画质比CBR好很多，但码率波动大。
WebRTC里VBR用得少，因为实时通信需要码率可预测。但在录制场景，比如本地录像或服务端录制，VBR是首选。我记得有一次做云端录制项目，用CBR录出来的视频，静态场景浪费带宽，运动场景糊成一片。换成VBR后，同样的平均码率，画质提升了一个档次。
VBR有两个关键参数：目标码率和最大码率。目标码率决定平均码率，最大码率限制峰值。设置不当会导致码率尖峰，网络扛不住。
注意：VBR模式下，如果最大码率设得太低，效果和CBR没区别。如果设得太高，网络拥塞时可能引发丢包。建议最大码率设为目标码率的1.5~2倍。
4.1.3 CRF（恒定质量）
CRF是x264/x265编码器特有的模式。它不直接控制码率，而是控制感知画质。CRF值范围0~51，值越小画质越好，文件越大。一般建议18~28之间。
CRF在WebRTC里几乎不用，因为码率完全不可控。但做离线转码或视频处理时，CRF是神器。我曾经用CRF 23转码一批教学视频，输出文件比源文件小40%，画质肉眼几乎看不出区别。
CRF的底层逻辑是：编码器根据画面复杂度自动调整QP，让每一帧的感知质量保持一致。运动场景多分配比特，静态场景少分配比特。效果确实好，但码率波动大到让网络模块崩溃。
经验之谈：如果你在做非实时场景的视频处理，优先用CRF。先设CRF=23跑一版，看看码率是否在可接受范围内。如果码率太高，增大CRF值；如果画质不够，减小CRF值。比手动调码率省心多了。
4.2 目标码率设置
目标码率怎么设？不是拍脑袋定的。WebRTC里，目标码率由带宽估计模块（比如GCC、REMBB）动态计算，编码器只是执行者。但作为开发者，你需要知道几个关键原则。
4.2.1 分辨率与码率的匹配关系
不同分辨率需要不同的码率才能保证基本画质。我整理了一个参考表，基于H.264编码，30fps场景：
| 分辨率 | 推荐码率范围 | 最低可接受码率 |
|---|---|---|
| 640×480 (480p) | 500~800 kbps | 300 kbps |
| 1280×720 (720p) | 1.5~2.5 Mbps | 800 kbps |
| 1920×1080 (1080p) | 3~5 Mbps | 1.5 Mbps |
| 3840×2160 (4K) | 10~20 Mbps | 5 Mbps |
注意，这只是参考值。实际项目中，我会根据内容类型调整。比如屏幕共享场景，文字多、运动少，码率可以降低30%~50%。而体育直播场景，运动剧烈，码率需要提高50%以上。
4.2.2 码率与帧率的权衡
码率固定时，帧率越高，每帧分配的比特越少。很多人以为帧率越高越好，其实不然。我遇到过有人把帧率设到60fps，码率只有1Mbps，结果每帧都糊，还不如30fps清晰。
一个简单的经验公式：每帧比特数 = 目标码率 / 帧率。如果每帧比特数低于某个阈值（比如480p下低于10kbits），画质就会明显下降。这时候要么降低帧率，要么提高码率。
避坑指南：我曾经在项目中为了追求流畅度，把帧率提到60fps，码率没变。结果用户反馈「画面模糊，看不清人脸」。后来降到30fps，码率不变，画质明显改善。流畅度和清晰度之间，需要找到平衡点。
4.3 码率波动控制
码率波动是实时通信的大敌。波动太大会导致网络拥塞控制算法误判，引发带宽震荡。WebRTC里控制码率波动的手段主要有三种。
4.3.1 VBV/HRD缓冲区
VBV（Video Buffering Verifier）是编码器内部的码率平滑机制。它规定了一个虚拟缓冲区，编码器输出的码流不能超过缓冲区的填充和清空速率。说白了，就是给码率波动加一个「缓冲垫」。
WebRTC的编码器实现中，VBV缓冲区大小通常设为码率对应的时间窗口，比如500ms。缓冲区越大，码率越平滑，但延迟越高。缓冲区越小，延迟低，但码率波动大。
我个人习惯在实时通信场景下，把VBV缓冲区设为200~300ms。既能有效抑制码率尖峰，又不会引入明显延迟。
4.3.2 QP限制与帧跳过
当编码器发现码率即将超标时，有两种应对方式：
- 增大QP：降低画质，减少比特数。这是首选方式，因为画质下降是渐变的。
- 跳过帧：直接丢弃某些帧，降低码率。这是最后手段，因为跳帧会导致卡顿。
WebRTC的编码器默认优先调整QP，只有当QP已经达到最大值（比如51）时，才会考虑跳帧。我在项目中遇到过一种情况：画面突然剧烈变化，QP瞬间冲到51，画质崩了。后来我限制了QP的最大值，比如设为40，宁可稍微跳帧，也不让画质崩得太难看。
注意：QP最大值设得太低，码率可能压不住。设得太高，画质无法接受。建议根据场景动态调整：弱网场景QP上限可以设高一些（45~48），正常网络设低一些（35~40）。
4.3.3 码率平滑算法
除了编码器内部的机制，WebRTC的Pacer模块也负责码率平滑。Pacer把编码器输出的数据包均匀地发送到网络上，避免突发流量。
Pacer的核心参数是发送间隔和突发大小。默认配置下，Pacer会把数据包均匀分布在每个时间片内。如果发现网络拥塞，Pacer会主动降低发送速率。
嗯，这里要注意：Pacer只能平滑发送端的码率，不能解决编码器输出本身的波动。所以编码器内部的码率控制才是根本。
4.4 三种模式的选型建议
说了这么多，到底怎么选？我总结了一张决策图，帮你快速判断。
4.5 实战：WebRTC中配置码率控制
最后，给一段实际代码。WebRTC中通过RTCRtpEncodingParameters配置码率控制参数。
// 创建视频编码器配置
const videoEncoderConfig = {
codec: 'H264',
width: 1280,
height: 720,
bitrate: 2000000, // 2 Mbps 目标码率
bitrateMode: 'cbr', // cbr | vbr | crf
frameRate: 30,
// 码率波动控制
bitrateWindow: 500, // VBV缓冲区大小，单位ms
maxBitrate: 2500000, // 最大码率，仅VBR模式有效
minBitrate: 1500000, // 最小码率，仅VBR模式有效
// QP限制
qpMin: 18,
qpMax: 40,
// 帧跳过策略
frameDropThreshold: 0.95, // 码率达到目标码率95%时允许跳帧
};
// 在RTCPeerConnection中应用
const transceiver = pc.getTransceivers()[0];
const sender = transceiver.sender;
const parameters = sender.getParameters();
parameters.encodings[0].maxBitrate = 2500000;
parameters.encodings[0].minBitrate = 1500000;
parameters.encodings[0].scaleResolutionDownBy = 1.0;
await sender.setParameters(parameters);小技巧：实际项目中，不要硬编码码率。监听RTCPeerConnection的oniceconnectionstatechange事件，根据网络状态动态调整码率。弱网时降低码率，网络恢复后提高码率。这才是WebRTC的正确用法。