4、编码延迟控制：编码器选择与配置、硬件编码 vs 软件编码、编码参数对延迟的影响

说到WebRTC的延迟，编码这块儿是绕不开的硬骨头。我见过不少团队，网络调得挺好，传输也顺畅，结果卡在编码上，延迟死活降不下来。说白了，编码器就是视频数据的“打包工”，打包慢了，后面全得等。

这一章，咱们就聊聊怎么让这个“打包工”手脚麻利点。

4.1 编码器选择：H.264、VP8、VP9 谁更“快”？

WebRTC里常见的编码器就那几种：H.264、VP8、VP9，还有新秀AV1。但论延迟控制，我个人习惯首选H.264。

为什么会这样？

• H.264：硬件支持最广，几乎所有的手机、电脑芯片都有硬编解码模块。延迟低，稳定。我在项目中遇到过，用H.264做1080p通话，编码延迟能稳定控制在5ms以内。
• VP8：Google的亲儿子，软件编码效率不错，但硬件支持不如H.264。延迟稍高，胜在开源免费。
• VP9：压缩率更高，但计算复杂度也高。软件编码延迟明显，适合对带宽敏感但对延迟不敏感的场景。实时通话里，我一般不太推荐。
• AV1：压缩率之王，但编码速度是硬伤。目前硬件编码器还没普及，软件编码延迟太高，实时场景基本不用。

4.2 硬件编码 vs 软件编码：一场关于“快”与“灵活”的博弈

这个选择题，我几乎在每个项目里都要做一遍。你想想看，硬件编码快，但死板；软件编码灵活，但吃CPU。

对比维度	硬件编码	软件编码
延迟	极低（1-5ms）	较高（5-20ms+）
CPU占用	极低（专用芯片）	高（吃主频）
画质	一般（固定算法）	优秀（可调参数多）
灵活性	差（参数受限）	高（几乎全可控）
适用场景	移动端、嵌入式、低功耗设备	服务器端、高性能PC、需要精细调优的场景

嗯，这里要注意。硬件编码虽然快，但不同厂商的芯片质量参差不齐。我曾经在某个国产平板上测试，硬件编码出来的画面有块效应，延迟虽然低，但画质没法看。后来还是切回了软件编码，牺牲了2ms延迟，换来了可接受的画质。

4.3 编码参数对延迟的影响：那些你不得不调的“旋钮”

选好了编码器，接下来就是调参了。这里有几个关键参数，直接影响延迟。

4.3.1 关键帧间隔（GOP/Keyframe Interval）

关键帧（I帧）是完整的图像，而P帧和B帧只记录变化。关键帧越大，压缩率越高，但延迟也越大。因为解码器必须等到一个完整的I帧才能开始解码。

我习惯把关键帧间隔设成2秒。太短了带宽浪费，太长了延迟累积。实时通话里，2秒是个不错的平衡点。

// 在WebRTC中设置关键帧间隔
const parameters = {
  encoder: {
    keyFrameInterval: 2000, // 单位：毫秒
  }
};

4.3.2 码率控制模式：CBR vs VBR

CBR（恒定码率）和VBR（可变码率）的选择，对延迟影响很大。

• CBR：码率恒定，编码器会尽量保持输出速率稳定。延迟可控，适合实时通话。但画质会有波动。
• VBR：码率可变，复杂场景用高码率，简单场景用低码率。画质好，但码率波动大，容易造成网络拥塞，延迟不稳定。

我个人习惯在WebRTC里用CBR。你想想看，实时通话最怕的就是码率忽高忽低，网络扛不住。CBR虽然牺牲了一点画质，但换来了延迟的稳定性，值。

4.3.3 编码复杂度预设（Preset）

软件编码器（比如x264）有预设参数，从ultrafast到placebo。预设越快，编码延迟越低，但压缩率也越低。

预设	延迟	压缩率	推荐场景
ultrafast	极低	低	实时通话、低延迟直播
superfast	低	中	一般实时场景
veryfast	中	高	画质优先的实时场景
faster/fast/medium	高	很高	非实时、点播

我在项目中一般用superfast。ultrafast虽然延迟最低，但码率会飙升，反而可能因为带宽不足导致丢包延迟。superfast是个不错的折中。

4.3.4 线程数（Threads）

软件编码可以设置线程数。线程越多，编码越快，但线程间同步开销也越大。一般建议设置为CPU核心数的一半或全部。

// 设置编码线程数
const encoderConfig = {
  numberOfThreads: 4, // 根据CPU核心数调整
};

4.4 编码延迟控制的核心逻辑

说了这么多，咱们用一张图来总结一下编码延迟控制的核心逻辑。

从原始视频帧到低延迟编码流，每一步的选择都直接影响最终延迟。我个人习惯的优先级是：编码器选择 > 硬件/软件决策 > 参数调优。先把大方向定好，再抠细节。

4.5 避坑指南：我曾经踩过的坑

最后，分享几个我实际项目中遇到的坑，希望能帮你少走弯路。

• 坑一：硬件编码的“黑盒”问题。我曾经在某个Android设备上，硬件编码出来的视频有2秒的延迟。查了半天，发现是芯片的编码器缓冲区太大。后来通过设置android.media.encoder.output.buffer.size参数解决了。
• 坑二：B帧带来的延迟。B帧需要参考前后帧，会引入额外的编码延迟。实时通话里，我建议禁用B帧。H.264里设置profile: baseline就能做到。
• 坑三：码率控制模式选错。有一次我用VBR做直播，结果码率波动太大，导致网络拥塞，延迟飙升到500ms。后来换成CBR，延迟立刻降下来了。