13、带宽估计：GCC算法、Transport-CC、带宽自适应调整
带宽估计，说白了就是让WebRTC自己判断“现在网络能跑多快”。
我刚开始做实时通信那会儿，总觉得这玩意儿是玄学。明明码率设好了，网络一抖，画面就卡成PPT。后来才明白，没有带宽估计，一切都是纸上谈兵。
这一章，我们就把GCC算法、Transport-CC和带宽自适应调整讲透。嗯，都是实战里天天打交道的东西。
13.1 为什么需要带宽估计？
你想想看，视频通话时，网络状况是动态的。Wi-Fi信号波动、4G切换基站、别人在下载大文件……这些都会影响可用带宽。
如果没有带宽估计，发送端要么拼命发数据导致网络拥塞，要么发得太少浪费带宽。结果就是：要么卡顿，要么模糊。
核心目标：在保证低延迟的前提下，最大化视频质量。
说白了，就是让编码器知道“现在能发多少，别多也别少”。
13.2 GCC算法：Google的看家本领
GCC（Google Congestion Control）是WebRTC默认的带宽估计算法。我最早接触它是在2016年，当时被它的设计思路惊艳到了——它用了两个独立的控制器。
13.2.1 基于延迟的控制器
这个控制器通过观察数据包到达时间的延迟变化，来判断网络是否开始拥塞。
- 原理：当网络排队延迟增加时，说明链路开始拥堵，需要降低发送速率。
- 关键指标：到达时间差（Inter-arrival time）和发送时间差（Inter-departure time）的差值。
- 状态机：正常（Normal）、过载（Overuse）、欠载（Underuse）。
我在项目中遇到过一个问题：延迟控制器对突发流量特别敏感。有一次，用户突然切换网络，延迟抖动很大，GCC直接就把码率砍到了最低。后来我调整了过载检测的阈值，才解决了这个问题。
实战技巧：如果你发现GCC在弱网环境下过于激进地降码率，可以尝试增大overuse_time_threshold参数。默认是10ms，我习惯调到15ms，效果会平滑很多。
13.2.2 基于丢包的控制器
这个控制器更简单粗暴——看丢包率。
- 丢包率 < 2%：认为网络良好，可以尝试增加码率。
- 丢包率 2% ~ 10%：保持当前码率。
- 丢包率 > 10%：认为网络拥塞，必须降低码率。
我曾经踩过一个坑：在无线网络环境下，偶尔的随机丢包会导致GCC误判为拥塞，频繁降码率。后来我加了丢包率平滑处理，用滑动窗口取平均值，效果立竿见影。
注意：丢包控制器和延迟控制器是协同工作的。最终带宽估计值取两者中的较小值。这是为了防止单一指标误判导致带宽估计失控。
13.3 Transport-CC：更精细的带宽反馈
Transport-CC（Transport-wide Congestion Control）是GCC的升级版。它不再依赖单个流的RTCP反馈，而是把所有RTP流放在一起做带宽估计。
我记得第一次看到Transport-CC的设计文档时，心里想：这才是工程化的正确姿势。
13.3.1 工作原理
- 发送端给每个RTP包打上一个传输序列号（Transport-wide sequence number）。
- 接收端收到包后，记录每个序列号的到达时间。
- 接收端定期（通常每100ms）发送一个Transport-CC反馈包，包含所有序列号的到达时间信息。
- 发送端根据反馈信息，计算延迟梯度和丢包情况，调整发送速率。
说白了，Transport-CC让带宽估计从“黑盒”变成了“白盒”。你能精确知道每个包在网络里经历了什么。
13.3.2 与旧版GCC的对比
| 特性 | 旧版GCC（基于RTCP） | Transport-CC |
|---|---|---|
| 反馈粒度 | 每个SSRC独立反馈 | 所有流统一反馈 |
| 反馈频率 | 约1秒一次 | 约100ms一次 |
| 延迟估计精度 | 低 | 高 |
| 对多流场景支持 | 差 | 好 |
| 带宽利用率 | 偏低 | 更高 |
我在实际项目中做过对比测试：在同样的弱网环境下，Transport-CC的带宽利用率比旧版GCC高出约15%~20%。这意味着用户能看到更清晰的画面。
13.4 带宽自适应调整的实战策略
算法再好，落地才是关键。下面是我在项目中总结的几个实战策略。
13.4.1 码率平滑
GCC的带宽估计值变化可能很剧烈。如果直接用它来控制编码器，画面会频繁跳变，用户体验极差。
// 伪代码：码率平滑示例
float smooth_bitrate = current_bitrate * 0.7 + target_bitrate * 0.3;
// 限制单次变化幅度
float max_change = current_bitrate * 0.2;
if (abs(smooth_bitrate - current_bitrate) > max_change) {
smooth_bitrate = current_bitrate + sign(smooth_bitrate - current_bitrate) * max_change;
}我习惯用指数移动平均来做平滑，配合单次变化幅度限制。这样既能快速响应网络变化，又不会让画面忽好忽坏。
13.4.2 分层编码配合
带宽自适应调整不是编码器单方面的事。我建议配合SVC（可伸缩视频编码）或Simulcast（ simulcast）一起使用。
- 带宽充足时：发送高分辨率、高码率流。
- 带宽下降时：丢弃增强层，只发送基础层。
- 带宽恢复时：逐步恢复增强层。
这样做的好处是：带宽变化时，画面不会突然中断，只是清晰度平滑变化。
我的经验：在Simulcast场景下，带宽估计值降到某个阈值时，可以提前切换到低分辨率流。不要等到带宽完全不够了再切换，那样会有明显的卡顿感。
13.4.3 带宽估计的“安全垫”
永远不要100%信任带宽估计值。我习惯在估计值上留10%~20%的余量。
// 实际使用的码率 = 估计带宽 * 安全系数
float safe_bitrate = estimated_bandwidth * 0.85;为什么要这样做？因为带宽估计有滞后性。当你发现网络变差时，其实已经拥塞了一小段时间了。留点余量，可以避免频繁触发拥塞控制。
13.5 核心流程图
下面这张图展示了GCC + Transport-CC的完整工作流程。我画这张图时，特意把关键路径标红了，方便你理解。
从这张图你可以看到：发送端发出RTP包，经过网络到达接收端。接收端记录到达时间，生成Transport-CC反馈包，再通过网络传回发送端。发送端的带宽估计器根据反馈数据计算延迟和丢包，最终输出估计带宽给码率控制器。
整个闭环的延迟通常在100ms~200ms之间。嗯，这个速度对于实时通信来说是可以接受的。
13.6 避坑指南
最后，分享几个我踩过的坑，希望能帮你少走弯路。
坑1：我曾经在弱网环境下，GCC的带宽估计值频繁在500kbps和1Mbps之间跳变。后来发现是延迟控制器的阈值设置得太敏感了。解决办法：增大overuse_time_threshold，并加入滞回区间。
坑2：Transport-CC反馈包在网络中也可能丢失。如果连续丢失多个反馈包，带宽估计器会因为没有输入数据而“僵死”。解决办法：实现一个超时机制，如果超过500ms没有收到反馈，主动降低码率。
坑3：带宽估计和编码器之间的交互延迟。如果编码器响应太慢，带宽估计已经降下来了，但编码器还在发高码率，就会导致拥塞。解决办法：让编码器支持实时码率调整，不要等到下一个关键帧才生效。
好了，这一章的内容就到这里。带宽估计是个系统工程，需要你不断调试和优化。记住：没有完美的算法，只有适合你场景的方案。