1. 课程导入
码率控制，说白了就是决定「每秒往网络里塞多少数据」。你想想看，视频通话时画面卡成幻灯片，多半就是码率控制没做好。我在项目中遇到过不少次，明明网络带宽够，但视频就是卡——后来发现是码率控制参数没调对。
什么是码率控制
码率控制，英文叫 Rate Control，是编码器根据网络状况动态调整输出码率的一套机制。它的核心目标很简单：在可用带宽内，尽可能提供最好的视频质量。
具体来说，码率控制会做这几件事：
- 估算当前可用带宽——网络是快是慢，延迟高不高
- 调整编码器参数——比如量化参数 QP、帧率、分辨率
- 平滑输出码率——避免码率忽高忽低，造成网络抖动
一句话总结：码率控制就是编码器和网络之间的「翻译官」。它把网络能承受的带宽，翻译成编码器能理解的参数。
为什么需要码率控制
没有码率控制会怎样？我举个例子你就明白了。
假设你正在跟客户视频会议，网络带宽突然从 5Mbps 掉到 500Kbps。如果没有码率控制，编码器还在按 5Mbps 往外推数据——结果就是：网络拥塞、丢包、画面冻结、声音断断续续。嗯，这场景我调试过不下十次。
码率控制要解决的核心问题有三个：
| 问题 | 表现 | 码率控制的应对 |
|---|---|---|
| 带宽过高 | 网络拥塞、丢包、延迟飙升 | 降低码率，减少数据量 |
| 带宽过低 | 画面模糊、帧率低 | 在可用带宽内优化质量分配 |
| 带宽波动 | 画面忽好忽坏、卡顿 | 平滑调整，避免剧烈变化 |
我曾经踩过的坑：有一次线上会议，用户反馈画面每隔几秒就卡一下。查了半天，发现是码率控制响应太快——网络刚抖了一下，码率就猛降，然后网络恢复了又猛升。这种「来回震荡」比不调还糟糕。后来我加了平滑因子，问题就解决了。
WebRTC 中的码率控制架构概览
WebRTC 的码率控制不是单一模块，而是一套闭环反馈系统。我个人习惯把它分成三层来看：
- 网络探测层——负责测量带宽、延迟、丢包率
- 带宽估算层——根据探测数据算出「可用带宽」
- 码率分配层——把估算出的带宽分配给视频、音频、数据通道
下面这张图，是我在项目中经常用来跟团队讲解的架构图：
三个核心模块详解
1. 网络探测层
这一层负责收集原始数据。WebRTC 主要靠三种方式：
- RTCP 包——接收端定期发回报告，包含丢包率、抖动、RTT
- REMB——接收端估算带宽，直接告诉发送端「你最多发这么多」
- TWCC——Transport Wide Congestion Control，通过传输层反馈精确测量延迟
我的经验：TWCC 是 WebRTC 后来加入的，精度比传统 RTCP 高很多。如果你的场景对延迟敏感（比如在线教育、远程手术），建议优先开启 TWCC。
2. 带宽估算层
这是码率控制的「大脑」。WebRTC 默认使用 GCC（Google Congestion Control） 算法。GCC 有两种模式：
| 模式 | 原理 | 适用场景 |
|---|---|---|
| 丢包率模式 | 丢包率超过阈值 → 降低码率 | 有线网络、丢包敏感场景 |
| 延迟梯度模式 | 延迟持续增加 → 降低码率 | 无线网络、延迟敏感场景 |
两种模式会同时运行，取更保守的那个结果。嗯，这里要注意：延迟梯度模式在 Wi-Fi 环境下容易误判，我调过好几次。
3. 码率分配层
带宽估算出来了，接下来就是「分蛋糕」。WebRTC 的分配策略大致是：
- 音频优先——音频码率固定，一般 32-64 Kbps
- 视频拿剩下的——但不会低于最低阈值（默认 30 Kbps）
- FEC/NACK 预留——重传和冗余包也要占带宽
关键参数：WebRTC 中 min_bitrate、max_bitrate、start_bitrate 这三个参数，直接决定了码率控制的「活动范围」。调优时，我一般先从这三个参数入手。
小结
码率控制不是玄学，它是一套可观测、可调试、可调优的系统。你只要理解了「探测 → 估算 → 分配 → 反馈」这个闭环，后面调参数就有方向了。
我个人习惯，拿到一个新项目，第一件事就是打开 WebRTC 的 webrtc::RateControlSettings，看看默认参数是什么。很多时候，默认参数是为 Google 的办公网络优化的，到了你的场景，可能完全不是那么回事。