编解码器（Codec）

什么是编解码器？

编解码器（Codec，压缩器-解压器或编码器-解码器）是将原始音视频数据压缩成更小格式以便传输，然后解压以供播放的软件或硬件。可以把它想象成一个翻译器，它接收来自摄像头和麦克风的大量数据，将其压缩到网络连接能够处理的大小，然后在另一端将其还原，使接收者能清晰地看到和听到你。

没有编解码器，大多数用户的视频通话将无法实现。未压缩的原始 1080p 30fps 视频需要大约 1.5 Gbps（千兆比特每秒）的带宽。即使是光纤互联网连接通常最多也只有 100-1000 Mbps 上传速度。编解码器将其压缩到 1-3 Mbps 以实现高质量视频通话——减少 500-1500 倍，同时保持看起来几乎与原始画面相同的视觉质量。

在 WebRTC 中，编解码器的选择至关重要。编解码器决定了通话质量、带宽需求、CPU 使用率、电池消耗，以及通话是否能在不同浏览器和设备之间正常工作。截至 2025 年，WebRTC 编解码器格局已经相当成熟，对于大多数用例都有明确的赢家。

编解码器工作原理

视频编解码器利用冗余性和人类感知的局限性：

空间压缩：在每一帧内，大片区域通常相似。编解码器存储一次模式并在其他地方引用它
时间压缩：连续的帧通常非常相似。编解码器偶尔存储完整帧（关键帧），后续帧只存储变化（增量帧）
感知压缩：人眼对某些细节不太敏感（如暗区域的精确颜色）。编解码器丢弃你无论如何也不会注意到的信息
数学变换：如 DCT（离散余弦变换）等技术将图像数据转换到频率空间，在那里压缩更高效

编码（压缩）端计算量大。现代编解码器可以动态调整编码复杂度——当 CPU 可用时，它们生成更小、质量更好的文件。当 CPU 受限时（电量低、运行许多应用），它们使用更快、更简单的编码，生成稍大的文件或较低的质量。

解码（解压）端通常快得多。这种不对称性是有意为之——一个人编码，但可能有多人解码（在广播或会议中），所以最好让编码器承担负担。

WebRTC 强制编解码器

RFC 7742 规定，所有 WebRTC 兼容浏览器必须支持某些编解码器以确保互操作性：

视频：VP8 和 H.264

每个 WebRTC 浏览器都必须支持 VP8 和 H.264 Constrained Baseline 配置文件。这保证了任何两个 WebRTC 客户端都可以使用至少一种通用编解码器建立视频通话，即使它们支持不同的高级编解码器集。

音频：Opus 和 G.711

每个 WebRTC 浏览器都必须支持 Opus 和 G.711（PCMA 和 PCMU 格式）。Opus 是首选——它在质量和效率上都更优秀。G.711 主要是为了与传统 VoIP 系统兼容。

视频编解码器详解

VP8（2008）

VP8 是 Google 于 2010 年发布的开放、免版税视频编解码器，WebRTC 强制要求支持。它是每个 WebRTC 实现都支持的基准编解码器。

优点：

100% 免费——无许可费，无专利顾虑
浏览器普遍支持
编码和解码的 CPU 使用率低
非常适合低延迟实时通信
在所有浏览器实现中都经过良好优化

缺点：

压缩效率已过时——相同质量下需要比新编解码器更多的带宽
硬件加速支持极少（大多数编解码是基于软件的）
不适合极低带宽场景

最适合：兼容性至关重要且带宽充足时。当新编解码器不可用时，使用 VP8 作为降级方案。

H.264/AVC（2003）

H.264（也称为 AVC）是历史上部署最广泛的视频编解码器。它用于蓝光、流媒体服务、智能手机以及几乎每个带屏幕的设备。

优点：

出色的压缩效率——优于 VP8，在典型比特率下与 VP9 竞争
几乎普遍的硬件加速（编码和解码）
非常成熟、优化良好的实现
由于硬件支持，功耗低
WebRTC 强制支持，确保兼容性

缺点：

许可费（尽管浏览器处理此问题，而非应用开发者）
在极低比特率下不如 VP9 或 AV1 高效
WebRTC 仅要求 Constrained Baseline 配置文件，不如 Main/High 配置文件高效

最适合：移动设备（硬件加速节省电池）、功耗效率重要的应用、与非 WebRTC 系统的互操作性。

VP9（2013）

VP9 是 Google 的 VP8 继任者，提供显著更好的压缩效果，同时保持免版税。

优点：

相同质量下比特率减少 50%
与 H.264 High 配置文件竞争，有时更好
完全免费和开源
非常适合低带宽场景
硬件解码器支持不断增长
所有主流浏览器都支持（Chrome、Firefox、Edge）

缺点：

编码的 CPU 使用率更高（是 VP8 的 1.5-2 倍）
硬件编码器支持有限（解码更常见）
Safari 不支持（Apple 更倾向 H.264/H.265）
由于编码复杂度，延迟略高于 VP8

最适合：带宽受限但 CPU 可用的桌面视频通话。屏幕共享从 VP9 的效率中受益良多。

AV1（2018）

AV1 是开放媒体联盟的最新免版税编解码器，旨在以更好的压缩效果取代 VP9。

优点：

比 VP9 压缩效果好 30%，比 H.264 好 50%
在极低比特率下质量卓越
完全免费和开源
面向未来——硬件支持快速增长
非常适合细微文本的屏幕共享

缺点：

编码的 CPU 密集度是 VP9 的 3-5 倍
在大多数设备上没有硬件加速，实时编码不实用
截至 2025 年，硬件编码器支持仍在发展中
在 WebRTC 应用中尚未广泛采用
由于编码复杂度，延迟较高

最适合：在强大机器上的广播、录制、屏幕共享。2025 年，AV1 主要用于单向流而非交互式视频通话。随着硬件支持改进，预计采用率会更广泛。

H.265/HEVC（2013）

H.265（高效视频编码）是 H.264 的继任者，提供双倍的压缩效率。

优点：

相同质量下比特率减少 50%
出色的硬件支持（75% Windows，99% macOS，86% Android，90% iOS）
硬件加速时功耗低
每比特率质量优越
现在 Chrome 136+ 和 Safari 支持

缺点：

复杂的许可情况（多个专利池）
截至 2025 年 Firefox 不支持
软件编码 CPU 密集度极高
浏览器支持依赖硬件解码器以避免许可费

最适合：基于 Safari 的应用、具有硬件 HEVC 支持的设备上的高质量通话、带宽敏感环境。Chrome 136+ 在检测到硬件支持时启用 H.265。

音频编解码器

Opus（强制，首选）

Opus 是 WebRTC 的首选音频编解码器，理由充分——它在技术上优于所有替代方案。

主要特点：

语音和音乐处理都非常出色
自适应比特率：6 kbps（窄带语音）到 510 kbps（全频段立体声）
低延迟（5-66.5ms 算法延迟）
免版税
在任何比特率下都比 AAC、MP3 质量更好
对数据包丢失有弹性

典型用法：语音通话 32-64 kbps（单声道），音乐或高质量语音 64-128 kbps（立体声）。

如果你的应用需要传输音频并且 Opus 可用（在 WebRTC 中总是可用），就使用 Opus。没有理由使用其他任何编解码器。

G.711（PCMA/PCMU）

G.711 是一个古老的编解码器（1972 年），使用简单的压扩将 16 位 PCM 音频压缩到 8 位，比特率为 64 kbps。

它在 WebRTC 中仅用于与传统 VoIP 系统兼容。对于 WebRTC 到 WebRTC 的通话，永远不要选择 G.711 而非 Opus——Opus 以更低的比特率和 CPU 使用率提供更好的质量。

WebRTC 中的编解码器协商

在信令阶段，对等点交换 SDP 提供和应答，按优先级顺序列出支持的编解码器。应答方选择双方都支持的编解码器，通常从提供方列表中选择第一个相互支持的编解码器。

例如：

对等点 A 提供：VP9、VP8、H.264
对等点 B 支持：H.264、VP8
结果：选择 VP8（A 优先级顺序中的第一个匹配）

你可以通过 SDP 修改（在发送前修改 SDP）来操纵此优先级顺序以优先选择某些编解码器。例如，如果你想优先使用 H.264 而非 VP8，可以在 SDP 中重新排序编解码器列表。

实用建议（2025 年）

一般视频通话

在具有硬件支持的设备上优先使用 H.264（大多数移动设备、现代笔记本电脑）。使用 VP8 作为通用兼容性的降级方案。对于 CPU 可用且带宽受限的桌面应用，考虑使用 VP9。

移动应用

始终优先使用 H.264。硬件加速显著节省电池——与软件 VP8 相比功耗降低 20-30%。在支持 H.265 的新设备上，H.265 提供更高的效率。

屏幕共享

VP9 在屏幕共享方面表现出色，特别是对于包含文本和锐利边缘的内容。如果编码器有足够的 CPU，AV1 甚至更好。H.265 在硬件加速时也以低 CPU 使用率在屏幕共享方面表现卓越。

广播/流媒体

使用基础设施支持的最高效编解码器：AV1 > VP9 > H.265 > H.264。由于广播涉及一个编码器和多个解码器，在编码中投入 CPU 是值得的。

低带宽

VP9 或 AV1 在极低比特率（低于 500 kbps）下提供最佳质量。H.264 和 VP8 在低于 300 kbps 时质量明显下降。

带宽消耗

720p 30fps 视频的典型比特率：

VP8：1.5-2.5 Mbps
H.264：1.0-2.0 Mbps
VP9：0.75-1.5 Mbps
H.265：0.5-1.0 Mbps
AV1：0.5-1.0 Mbps

音频（Opus）：语音 32-64 kbps，音乐 64-128 kbps

这些是指南。实际比特率根据内容复杂度（说话的头部 vs 快速运动）、编码器设置和自适应比特率调整而变化。

未来：硬件加速

2025 年的编解码器格局越来越受硬件支持的影响。截至 2025 年：

H.264：通用硬件支持（编码和解码）
H.265：广泛的硬件解码（跨平台 75-99%），编码器支持不断增长
VP9：常见硬件解码，罕见编码器支持
AV1：新设备中硬件解码不断增长（Intel Arc、AMD RDNA 3、Apple M3+），编码器支持刚刚出现
VP8：仍主要是软件实现

预计随着硬件编码器在消费设备中成为标准，AV1 采用将在未来 2-3 年内急剧加速。到 2027-2028 年，AV1 可能在部署上与 H.264 匹敌。

总结

编解码器是使 WebRTC 变得实用的无形劳动力。没有它们，视频通话将需要几乎没有人拥有的互联网速度。有了它们，即使在普通连接甚至移动网络上，高质量视频通话也能运行。

在 2025 年，编解码器的选择对优化比对基本功能更重要。VP8 和 H.264 保证兼容性。VP9 和 H.265 在支持的地方提供更好的效率。AV1 是未来，但在大多数设备上尚不适用于实时编码。Opus 在音频编解码器战争中取得了决定性胜利——没有竞争对手。

对于大多数应用，一个简单的策略有效：移动端优先使用 H.264（硬件加速），带宽受限时桌面端优先使用 VP9，音频始终使用 Opus。这涵盖了 95% 的用例并取得了出色的结果。

参考资料

WebRTC 编解码器 - 支持哪些？ - Stream
WebRTC 使用的编解码器 - 媒体 - Mozilla 开发者网络
WebRTC 视频和屏幕共享编解码器对比 - WebRTC for Developers
WebRTC 视频编解码器世代：从 VP8 和 H.264 到 VP9 和 AV1 - BlogGeek.me
AV1 vs VP9 vs VP8：编解码器对比指南 2025 - Red5
H.264 vs H.265 vs VP9。2025 年如何选择正确的编解码器？ - Red5
H.264 vs VP8：哪个是更好的 WebRTC 编解码器？ - BlogGeek.me
准备发布：WebRTC 中的 H265（HEVC）编解码器支持 - Chromium