3、应用场景分析（一）：实时通信场景（WebRTC、视频会议）对编解码器的要求

实时通信，说白了就是“不能等”。你对着屏幕说话，对面要是延迟个两三秒才听到，这对话基本就崩了。WebRTC 和视频会议这类场景，对编解码器的要求跟点播完全不一样。点播可以花时间压得更小，实时通信不行——你得在“画质”、“带宽”和“延迟”这三者之间找平衡。

我这些年做过不少实时音视频项目，从早期的 SIP 软终端到后来的 WebRTC 网关，踩过的坑不少。今天咱们就聊聊，实时通信场景到底对编解码器提了哪些硬性要求。

3.1 低延迟：实时通信的第一道坎

实时通信的延迟，通常要求端到端在 200ms 以内。超过 400ms，人就能明显感觉到“卡顿”或“不同步”。编解码器本身会引入多少延迟？我列个表给你看。

编解码器	算法延迟（典型值）	帧大小依赖	是否适合实时通信
H.264（Baseline）	~1 帧（约 16ms @ 60fps）	低	✅ 适合
VP8	~1 帧	低	✅ 适合
VP9	~3-5 帧	中	⚠️ 需调优
AV1	~5-10 帧	高	❌ 不推荐
H.265（HEVC）	~2-3 帧	中	⚠️ 需硬件加速

为什么 AV1 延迟高？因为它用了更复杂的编码工具，比如更大的块划分、更精细的运动搜索。这些工具在离线编码时是宝贝，但在实时场景里就成了累赘。我记得有一次在嵌入式设备上试 AV1 实时编码，延迟直接飙到 300ms 以上，根本没法用。

3.2 带宽自适应：网络不会一直好

你想想看，视频会议的时候，网络突然变差了怎么办？编解码器不能“死脑筋”地按固定码率编码。它得能动态调整。

WebRTC 里有个概念叫 拥塞控制。编码器收到反馈说“网络堵了”，就得立刻降低码率。怎么降？无非三种手段：

1. 降低分辨率：从 720p 降到 480p，甚至 360p。
2. 降低帧率：从 30fps 降到 15fps。
3. 提高量化参数（QP）：画面变模糊，但码率降得快。

这里有个坑——码率切换的平滑性。我见过一些实现，码率突然从 2Mbps 降到 200kbps，画面直接“碎”掉，然后花了好几秒才恢复。这就是编码器内部状态没处理好。

3.3 错误恢复：丢包不可怕，可怕的是不会恢复

实时通信走的是 UDP，丢包是家常便饭。编解码器得能扛得住丢包。这里有两个关键机制：

• 参考帧管理：编码器不能把所有的帧都依赖前一帧。一旦丢了一个关键参考帧，后面一连串帧都得花掉。
• 关键帧请求：解码器发现画面坏了，得能主动请求编码器发一个关键帧（I帧），重新开始。

WebRTC 里有个 NACK（Negative Acknowledgment） 机制，就是干这个的。但 NACK 不是万能的——如果丢包率超过 20%，NACK 重传也救不回来。这时候就得靠 FEC（前向纠错）。

3.4 计算复杂度：别把 CPU 跑满

实时编码是计算密集型的。你不可能让用户的手机或者笔记本风扇狂转。编解码器的计算复杂度直接影响用户体验。

我一般用 编码一帧所需的时间 来衡量。如果编码一帧需要 20ms，而帧间隔是 33ms（30fps），那 CPU 占用率就是 60% 左右。超过 80%，用户就会感觉到卡顿。

编解码器	软件编码复杂度	硬件加速支持	推荐场景
H.264	低	广泛	全平台通用
VP8	低	中等	WebRTC 首选
VP9	中	有限	桌面端可用
AV1	高	极少	不推荐实时

嗯，这里要注意——硬件加速不是万能的。有些手机芯片的 H.264 硬件编码器，在低码率下画质还不如软件编码。我建议你在选型时，一定要拿真实设备跑一下，别只看 spec sheet。

3.5 实时通信场景的编解码器选型逻辑

说了这么多，咱们总结一下。实时通信场景下，编解码器的选型逻辑其实就三条：

1. 延迟优先：算法延迟必须低，不能为了压缩率牺牲延迟。
2. 带宽自适应：编码器必须能动态调整码率，且切换平滑。
3. 错误恢复：能扛丢包，能快速恢复画面。

下面这张图，是我自己画的一个选型决策流程，你可以参考一下。

说白了，实时通信场景下，VP8 和 H.264 Baseline 是当前最稳妥的选择。它们延迟低、带宽自适应成熟、硬件支持广泛。VP9 和 H.265 可以用于带宽更紧张的场景，但前提是你有硬件加速，并且能接受稍高的延迟。至于 AV1，我个人建议再等两年——等硬件编码器普及了再说。