14、自适应码率（ABR）：ABR 在 WebRTC 中的实现、基于分辨率与帧率的调整、ABR 与用户体验

大家好，我是你们的老朋友。今天我们来聊聊 WebRTC 里一个非常核心的话题——自适应码率，也就是 ABR。

说实话，我刚入行做实时通信那会儿，觉得 ABR 不就是根据网络好坏调一调码率嘛，有啥难的？结果第一次上线就被用户骂惨了——画面卡成幻灯片，声音倒是挺流畅。后来我才明白，ABR 远不止调码率那么简单，它背后是一整套关于“如何在有限带宽下，给用户最好的体验”的博弈论。

ABR 在 WebRTC 中的实现

WebRTC 的 ABR 机制，说白了就是一套“看菜下饭”的逻辑。网络带宽宽裕，我就给你高清大餐；网络紧张，我就给你标清简餐。但这里的关键是——怎么“看菜”？怎么“下饭”？

WebRTC 内部有一个叫 GCC（Google Congestion Control） 的模块，它负责实时监测网络状态。GCC 会收集两个关键指标：

• 丢包率：如果丢包率超过某个阈值（比如 2%），说明网络开始拥堵了。
• 往返时延（RTT）：RTT 突然增大，也是网络拥堵的信号。

基于这些指标，GCC 会估算出一个“目标码率”。然后，编码器（比如 VP8、VP9、H.264）就按照这个目标码率来压缩视频。

我在项目中遇到过一个问题：明明网络带宽足够，但视频还是卡。排查了半天，发现是编码器的码率控制模式设置成了 CBR（恒定码率），导致它不会根据网络波动动态调整。后来改成 VBR（可变码率），问题就解决了。嗯，这里要注意，WebRTC 默认用的是 VBR 模式，但有些第三方封装可能会改掉这个设置。

基于分辨率与帧率的调整

ABR 调整码率，通常有两种手段：调整分辨率 和 调整帧率。这两种方式对用户体验的影响完全不同。

调整分辨率

降低分辨率，说白了就是把画面从 1080p 降到 720p，甚至 360p。这样做的好处是码率下降非常明显，但代价是画面变模糊了。

举个例子：

分辨率	推荐码率（kbps）	画面清晰度
1920x1080	2500-4000	高清
1280x720	1500-2500	标清
640x360	500-1000	模糊

我个人习惯是，优先降低分辨率，而不是帧率。为什么？因为人眼对清晰度的敏感度其实没那么高，但对“卡顿”非常敏感。你想想看，画面模糊一点，用户还能接受；但画面一卡一卡的，用户立马就炸了。

调整帧率

帧率调整，就是减少每秒显示的帧数。比如从 30fps 降到 15fps，甚至 10fps。这样做的好处是画面清晰度不变，但运动画面会变得不流畅。

我曾经做过一个实验：把帧率从 30fps 降到 15fps，码率下降了大约 40%。但用户反馈说“画面像在放慢动作”。所以，帧率调整更适合那些运动场景不多的应用，比如在线教育、远程医疗。如果是视频会议或者游戏直播，降低帧率会严重影响体验。

ABR 与用户体验

ABR 做得好不好，直接决定了用户会不会骂娘。我总结了一个“用户体验三要素”：

1. 流畅度优先：卡顿是用户体验的头号杀手。宁可画面模糊一点，也不要卡顿。
2. 快速响应：网络变差时，ABR 要快速降码率，不能等用户卡了 5 秒才反应过来。
3. 平滑过渡：码率变化不要太突兀。从高清突然降到模糊，用户会感觉“是不是设备坏了”。

WebRTC 的 ABR 机制在流畅度上做得不错，但在平滑过渡上还有改进空间。我记得有一次，用户反馈说“画面突然变糊，然后又突然变清晰，来回跳”。这就是 ABR 的“震荡”问题——码率在高低之间反复横跳，导致用户体验极差。

怎么解决？我一般会在 ABR 算法里加一个“滞回区间”。比如，降码率的阈值是丢包率 2%，但升码率的阈值是丢包率 0.5%。这样就不会因为网络轻微波动而频繁调整码率。

ABR 核心逻辑流程图

下面这张图是我自己画的 ABR 核心逻辑，你看一眼就能明白整个流程：

这张图的核心逻辑很简单：GCC 先估算带宽，然后判断带宽是否充足。如果充足，就提升码率；如果不充足，就降低码率。降低码率时，优先降分辨率，再降帧率。最后编码发送，同时把网络状态反馈给 GCC，形成闭环。

好了，关于 ABR 的实现和调整策略，今天就聊到这里。记住一句话：ABR 不是技术问题，而是用户体验问题。你调得再好，用户觉得卡，那就是失败。所以，多站在用户的角度去思考，你的 ABR 方案才能落地。

---