4. WebRTC 低延迟配置：编码器选择、码率控制与抗丢包策略
WebRTC 的低延迟，说白了就是跟网络条件做博弈。你编码器选错了，码率控制没调好，或者抗丢包策略没配对，延迟立马就上去了。这一章，我把我在多个实时项目中踩过的坑和总结的经验，一次性讲清楚。
核心观点： 没有最好的编码器，只有最适合你场景的编码器。码率控制是延迟的“油门”，FEC 和 NACK 是“安全带”，三者必须协同调优。
4.1 编码器三选一：H.264、VP8、VP9 怎么挑？
WebRTC 默认支持 H.264、VP8 和 VP9。我个人的选择逻辑很简单：看终端、看算力、看延迟要求。
| 特性 | H.264 | VP8 | VP9 |
|---|---|---|---|
| 硬件编码支持 | 最广泛（几乎所有设备） | 较少 | 较新设备支持 |
| 编码效率 | 中等 | 中等 | 高（同等画质码率低 30-50%） |
| 编码延迟 | 低（硬件编码可极低） | 低 | 较高（计算复杂度高） |
| 浏览器兼容性 | Chrome、Firefox、Safari 均支持 | Chrome、Firefox 支持 | Chrome 支持，Safari 部分支持 |
| 适合场景 | 全平台互通、移动端 | 纯软件编码、低端设备 | 高画质低码率、桌面端 |
我的建议：
- 移动端优先选 H.264。iPhone 和大部分 Android 手机都有硬件编码器，功耗低、延迟稳。我在做移动直播 SDK 时，用 H.264 硬件编码，端到端延迟能控制在 200ms 以内。
- 桌面端或纯软件编码，可以试试 VP9。VP9 的编码效率确实高，但计算量也大。我记得有一次在低配笔记本上开 VP9，CPU 直接飙到 90%，延迟反而比 H.264 还高。所以，算力不够就别硬上。
- VP8 作为兜底。如果 H.264 硬件编码不支持，VP9 又太慢，VP8 是个稳妥的选择。它兼容性好，编码延迟也低。
避坑指南： 我曾经在跨平台项目中，默认启用了 H.264 的 Simulcast（多流）。结果发现某些 Android 设备只支持单流 H.264，导致接收端黑屏。后来我加了一层能力协商，根据对端支持的编码器动态切换，才解决问题。
4.2 码率控制：别让编码器“放飞自我”
码率控制直接影响延迟。如果码率设置过高，网络拥塞，延迟飙升；设置过低，画质变差，用户又抱怨。WebRTC 提供了几种码率控制模式，我重点讲两个：CBR（恒定码率） 和 VBR（可变码率）。
- CBR： 码率恒定，适合带宽稳定的场景。延迟可控，但画质会有波动。
- VBR： 码率随画面复杂度变化，适合带宽充裕的场景。画质稳定，但延迟可能波动。
我个人习惯在实时通信中用 CBR。为什么？因为延迟的稳定性比画质的瞬时波动更重要。你想想看，视频会议里画面偶尔模糊一下可以接受，但延迟忽高忽低，对话就断断续续了。
下面是一个典型的 WebRTC 码率配置示例：
// 创建 RTCPeerConnection
const pc = new RTCPeerConnection({
iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
// 获取视频轨道
const stream = await navigator.mediaDevices.getUserMedia({ video: true });
const videoTrack = stream.getVideoTracks()[0];
// 创建发送器并设置码率参数
const sender = pc.addTrack(videoTrack, stream);
const parameters = sender.getParameters();
// 设置编码器优先级和码率
parameters.encodings = [
{
rid: 'high',
active: true,
maxBitrate: 1500000, // 1.5 Mbps
minBitrate: 500000, // 500 Kbps
scaleResolutionDownBy: 1.0
}
];
// 应用参数
await sender.setParameters(parameters);
注意：
setParameters 必须在 addTrack 之后、createOffer 之前调用。否则参数可能不生效。我遇到过好几次因为调用顺序不对，码率控制完全没起作用的情况。
4.3 FEC 与 NACK：抗丢包的“双保险”
网络丢包是低延迟的天敌。WebRTC 提供了两种抗丢包机制：FEC（前向纠错） 和 NACK（否定确认）。它们各有优劣，需要配合使用。
| 特性 | FEC | NACK |
|---|---|---|
| 工作原理 | 发送冗余数据包，接收端直接恢复 | 接收端请求重传丢失的数据包 |
| 延迟影响 | 低（无需等待重传） | 高（需要 RTT 时间） |
| 带宽开销 | 高（冗余数据占用带宽） | 低（只在丢包时重传） |
| 适用场景 | 丢包率低、延迟敏感 | 丢包率高、带宽有限 |
我的实战策略：
- 丢包率 < 5%： 只用 NACK。FEC 的带宽开销不划算。
- 丢包率 5%-15%： 启用 FEC，但控制冗余比例。我一般设置 20% 的冗余，也就是每 5 个数据包加 1 个冗余包。
- 丢包率 > 15%： FEC + NACK 同时启用。但这时候要考虑降低码率或分辨率，否则带宽可能撑不住。
WebRTC 默认启用了 NACK，但 FEC 需要手动配置。下面是一个启用 FEC 的示例：
// 在 SDP 中启用 FEC
const sdp = pc.localDescription.sdp;
const modifiedSdp = sdp.replace(
'a=rtpmap:100 VP8/90000',
'a=rtpmap:100 VP8/90000\r\na=rtcp-fb:100 nack\r\na=rtcp-fb:100 nack pli\r\na=fmtp:100 x-google-flag:1'
);
// 重新设置 SDP
await pc.setLocalDescription({ type: 'offer', sdp: modifiedSdp });
避坑指南： 我曾经在一个跨国会议项目中，发现 FEC 的冗余包反而加剧了网络拥塞。原因是丢包率已经很高了（超过 20%），FEC 的冗余数据占用了大量带宽，导致更多丢包。后来我改成动态调整 FEC 冗余比例，根据实时丢包率自动增减，才稳定下来。
4.4 知识体系总览
下面这张图，把编码器选择、码率控制和抗丢包策略的关系梳理清楚了。你可以把它当作调优的“路线图”。
4.5 总结：调优的“黄金三角”
编码器、码率控制、FEC/NACK，这三个点构成了 WebRTC 低延迟配置的“黄金三角”。
- 编码器选对了，延迟的起点就低。
- 码率控制调好了，延迟就不会忽高忽低。
- FEC/NACK 配好了，丢包就不会导致卡顿。
嗯，这里要注意：没有一套配置能适应所有网络。我建议你在项目中加入实时监控和动态调整逻辑，根据丢包率、RTT 和带宽自动切换策略。这才是低延迟调优的终极方案。