webrtc opus音频编码的发展

如果我们看 WebRTC 近十年的音频编码，那其编码器其实就是 Opus。当然也有 G.711 音频编码，但是 WebRTC 并不采用它。图 1 是 Opus 主页一张很有名的图，是 Opus 和其他音频编码器的比较，证明其具有最佳的编码性能。这张图横坐标是比特率，纵坐标是质量，相同比特率下当然质量越高，编码器性能越佳。

Opus 可以视作两种编码器的组合。SILK 为语音编码的性能与 Opus 曲线前半段相近，而 CELT 是专门为音乐音频编码的编码器，其性能在高码率段与 Opus 相近。SILK 有三种设置，一种为窄频带，一种为宽频带，另外一种为全频带。CELT 也有两种模式，一种是全频带音频，一种是全频带立体声。

Opus 的性能是逐年提升的。在 2017 年，V1.2 在我们的政策中全频带范围达到 14 kbps，音乐音频的频带达到 32kbps。在 2018 年, V1.3 中宽频带达到 9kbps，而 SILK 扩展到 5 kbps。在 2022 年我们有了两个新的编码方式，一个是 Lyra，分别在 2021 和 2022 发布了两个版本。另外一个是在 2021 年由微软推动的 Satin。如图 2 所示，这两个编码器在左下角低码率处（图中红色箭头处）大大提高了编码质量，但是这两个编码器的优化对 CPU 和终端电池造成了极大的负担。

Lyra and Satin

Lyra 是专门为低带宽时设计的音频编码器。从图 3 中可以看到，10 kbps 内 Lyra 的性能都要优于 Opus。当带宽大于 10kbps 的时候，你就可以切换 Opus，因为 Lyra 是一种独立编码仅针对低带宽的场景。LyraV2 相较于 LyraV1 也实现了大的性能提升，LyraV1 的编码算法延迟仍然有 100ms，在 RTC 场景下难以使用，而 LyraV2 仅需要 20ms。

Lyra 已经有人在浏览器中实现了 demo, 你可以尝试在低码率条件下运行该 demo，仍然能感受到听到的音频质量不错。

Satin 与 Lyra 不同，Satin 可以说是 Opus 的一个扩展。Satin 分为两种模式，低码率和高码率模式，并且可以实现这两种模式的无缝切换。Satin 在不同的帧大小下，维持一个稳定的性能，且延迟仅有 20ms 可以满足 RTC 要求。同时其可以在 6 kbps 下支持超宽频带如图 5 所示，并且性能与 Opus 和 G.711 不相上下。

所以我们接下来该怎么做？等待新版本 Opus 1.4？还是像 Google 开发 Lyra 这样重新研发一种新的音频编码方式？还是采用多音频编码策略？

其实不用这么麻烦。首先让我们来看 Opus 的格式，如图 6 所示。Opus 的格式其实是一种容器格式。第一个 bit 描述了剩下包的格式。而且不需要 SDP 协商，因为协商是通过带间通信实现的。

即使你拥有了完美的音频编码技术，丢包是你仍然需要考虑的问题。就像图 7 所示，当发生了丢包，音频波形会中间会出现 20 ms 的空白。我们可以通过伪装该丢包并未发生，这种技术叫做 PLC(packet loss concealment)。可以将该段用白噪声或者不发声片段来代替，不过这已经是 20 年前的方法了。或者像 WebRTC jitter buffer 中的 Neteq 在丢包期间一直重复上一个音频帧，幅度与原始音频帧略有不同。这种方法对 20ms 的丢包间隔有用，但是如果有 60 ms 的丢包间隔，就会失效。最近两年比较新颖的方法，是用 AI 模型根据已有音频波形生成一段新波形来替代丢失的音频轨，已经应用在 Microsoft team 和 Google Duo 的 Neteq 中。

从另外一个角度考虑，如果发生了丢包，发端可以做些什么？在 WebRTC 中有几种方法可以解决丢包问题，被称为 Audio Resilience。最基本的方法就是丢包发生时，由收端向发端反馈 NACK，开销一般较小，适用于低带宽低延迟零星丢包的网络环境，由 SDP 控制。WebRTC 并没有 NACK 标准，且默认不开启重传。音频丢包也可以使用 FEC 方法恢复，FEC 在上面已经介绍过，不再赘述。

还有一种方法叫做 RED。RED 就是将过去的几个包做一个完全复制，然后一起附在原始包发送后发送。这种方法仅适用于高带宽，高丢包的情况，且开销很大，由可插入的流控制，WebRTC 仅支持部分 Red 标准。

展望

音频编码未来将会怎样发展呢？我们目前能做的有哪些？

可以考虑：

1. 使用带有 WASM 的 Lyra
2. 将 Lyra 整合进 Opus
3. 使用低开销的冗余策略
4. 直接使用可插入流

来自Kranky Geek WebRTC 2022 秋季大会演讲。