1. WebRTC 与码率控制概述

WebRTC 说白了就是一套让浏览器之间能直接音视频通话的协议栈。我刚开始接触它的时候，觉得这东西就是个黑盒子——打开摄像头，塞进 PeerConnection，对面就能看到画面了。但真正做深了才发现，里面的码率控制才是灵魂。

一个典型的 WebRTC 架构包含这么几层：

这里面最核心的，其实是码率控制层。为什么？因为网络是动态的，带宽会抖动，丢包会突发。如果没有码率控制，编码器按固定码率输出，网络一堵就全崩了。

核心观点：WebRTC 的码率控制不是独立模块，而是贯穿采集、编码、传输、渲染全链路的闭环反馈系统。

我画了一张架构图，帮你理清各层之间的关系：

码率控制到底在控什么？我个人的理解是三个字：稳、清、低。

目标	含义	我在项目中遇到的坑
稳	视频不卡顿、不花屏、不频繁缓冲	有一次带宽突然从 5Mbps 掉到 500kbps，码率没及时降下来，画面直接卡死 3 秒
清	在可用带宽内最大化视频质量	带宽充足时码率却上不去，画面糊得像马赛克——后来发现是码率预估算法太保守
低	延迟尽可能小，交互体验流畅	为了追求清晰度把码率拉满，结果延迟飙到 500ms，对方说话 2 秒后才听到

这三个目标其实是互相矛盾的。你想想看，要稳就得留余量，但余量大了清晰度就下降；要清晰就得用高码率，但高码率在弱网下必然卡顿。码率控制说白了就是在三者之间找平衡点。

我的经验：不要试图在所有场景下都做到最优。先明确你的业务场景——是视频会议（重稳）、直播（重清）、还是远程协作（重低延迟），然后针对性地调优。

做码率控制这么多年，我总结下来有四大挑战：

网络不可预测：Wi-Fi 信号波动、4G/5G 切换、小区拥塞，这些都不是我们能控制的。我记得有一次在高铁上测试，带宽每 10 秒就剧烈抖动一次，码率控制根本来不及反应。
延迟敏感：WebRTC 要求端到端延迟在 200ms 以内。传统的 TCP 拥塞控制（比如 Cubic）在丢包时重传，延迟会飙升到秒级，完全不能用。
多流竞争：一个 PeerConnection 里可能同时有视频、屏幕共享、音频等多条流，它们共享同一个网络通道。怎么分配码率？优先级怎么定？
编码器差异：VP8、VP9、H264 的码率控制接口和响应速度都不一样。我踩过最深的坑是 VP9 的码率切换延迟比 VP8 高了 2 倍，导致码率控制震荡。

避坑指南：我曾经在项目中直接用了 WebRTC 默认的码率控制参数，结果在 30% 丢包率下画面直接崩了。后来才发现，默认参数是针对有线网络优化的，移动网络必须单独调。

我把整个流程拆成 5 步，你跟着走一遍就清楚了：

步骤	模块	做什么	输出
1	发送端码率预估	基于丢包率、RTT、抖动，用 GCC 或 REMB 算法估算可用带宽	目标码率（如 1.2 Mbps）
2	编码器目标码率设置	把预估码率传给编码器，设置目标码率和最大/最小码率	编码器参数更新
3	编码输出	编码器按目标码率压缩视频帧，输出码流	编码后的 RTP 包
4	网络传输	RTP 包经过网络到达接收端，可能发生丢包、延迟、抖动	接收端收到的包序列
5	接收端反馈	接收端统计丢包率、到达时间、抖动，通过 RTCP 反馈给发送端	RTCP Receiver Report

这 5 步形成一个闭环，每 100ms 左右循环一次。嗯，这里要注意：闭环的响应速度决定了码率控制的实时性。如果反馈太慢，码率调整就会滞后，导致要么带宽浪费，要么网络过载。

关键指标：码率控制的收敛时间——从网络变化到码率调整到位的时间。我一般要求这个值在 500ms 以内，超过 1 秒用户就能感知到卡顿。

这一章我们聊了 WebRTC 的实时通信架构，重点解剖了码率控制层的位置和作用。码率控制的核心目标就是稳、清、低三者平衡，而挑战主要来自网络不可预测、延迟敏感、多流竞争和编码器差异。

我个人觉得，理解码率控制最好的方式就是把它当成一个闭环反馈系统——发送端预估、编码器执行、网络传输、接收端反馈，然后循环往复。后面的章节我们会深入每个环节的算法细节和调优技巧。