编解码器杂谈:浅析 Opus

作者:赵晓涵,声网 Agora 音频算法工程师。原文首发于 RTC 开发者社区

谈起 Opus,对于编解码器有所了解的同学也许会知道,Opus 是由两个编解码器——Silk 和 Celt 融合而成。为什么来自两个组织的编解码器会合二为一,Opus 的性能又如何,本文将简述一下 Opus 的前世今生和部分技术分析。

提到 Opus,就不得不提到它的主要作者,Jean Marc Valin,他从学生时代就开始致力于高音质编解码算法的实现,著名的编解码器 Speex 也是他的作品之一。时间回到2007年,Jean Marc Valin 在博士后期间,完成了 Speex 的开发。在当时,业内编解码器主要分为两个流派:高延时的音乐编解码器(如 MP3、AAC 和 Vorbis)和低延时的语音编解码器(AMR、Speex、G.729)。而工业界对低延时音乐编解码器的需求越来越高,于是 Celt 的开发也被提上了日程。Celt 的早期目标是实现 4-8ms 的编码延时,相比当时 MP3 和 AAC 编码的 100ms+ 延时,优势是非常巨大的。

在研发过程中,Jean Marc Valin 和其他开发者始终围绕着 Vorbis 作者 Christopher “Monty” Montgomery 的意见“尽量保持信号能量谱的低失真”进行开发,这也是 Celt(Constrained Energy Lapped Transform)名字的由来。第一版 Celt 的研发持续了两年,但因为需要保证低延时的原因,Celt 的表现并没有超过 MP3 和 AAC。但在经过了持续六个月的改进后(使用了部分 MP3 的技术),Celt 的表现第一次超过了 MP3。也就是在那个时候,Celt 逐渐走出实验室,迎来了它在工业界的第一批使用者–部分用户因为低延时的强需求不得不选择了 Celt。也就是这一批最早期的用户给了 Celt 的开发者们宝贵的反馈,使其不断改进 Celt。

在开发 Celt 的同时,另一批来自 Skype,以 Koen Vos 为首的开发者开发了业内领先的语音编解码器 Silk,并将其提交至 IETF,作为一款免版税的开源编解码器。Celt 也紧随 Silk 的步伐进行了提交。但 Silk 和 Celt 都遭遇了很大的阻力,这个阻力的来源更多的不是技术因素,而是『政治』因素:此前有大量投资者投资了带版税的编解码器,这些投资者在业内的权威也很大。正是这些阻力促使 Silk 和 Celt 结合到一起,诞生了 Opus。在 Opus 里,Silk 主要负责处理 16khz 及 8khz 的信号,而 Celt 则能处理 8khz 以上的信号。实际上,关于 Opus 里 Silk 和 Celt 的工作模式并不仅仅这么简单,Opus 里共有 32 种模式用来处理不同种类的信号。Opus编解码器架构如下。

编码器:


解码器:


为了和 Silk 结合,Celt 做出了一定的改动。之前 Celt 为了极低延时,把帧长设置的比较短,但 Silk 需要 20ms 的帧长,于是 Celt 牺牲了部分延时和 Silk 的帧长对齐,但仍能把整体延时控制在 10ms。Opus 诞生后又经过了很多改进,关键的改进来自于 Broadcom 提供的一种滤波器,这个滤波器在编码端和解码端各有一个。在编码端,前置滤波器可以保留音乐信号的低频部分,减弱高频部分,这样就可以更高效的去编码;在解码端,后置滤波器可以近乎无损的把被减弱的高频恢复出来。这种前置-后置滤波器结合上述拉长到 20ms 的帧长,Opus 第一次在音乐音质和压缩率上超过了 HE-AAC。这对于 Opus 来说是一个非常重要的节点,因为这代表着 Opus 在语音、音乐、复杂度和延时上有了全面超越其他编解码器的能力。

而融合进 Opus 的 Silk 模块改动则不是很大,主要的改动点都是非常小的细节,我简单整理了一些,如下所示:

一、线性预测部分:二者的计算逻辑是相同的。不同之处有:

  1. OPUS 的整体计算精度更高一些,由 Silk 里的 Q10 转换成了 Q14 后进行判断,包括短时预测、长时预测和激励部分。
  2. 在做 Delaydecision(一种延时选择算法,可以令标量量化拥有近似矢量量化的效率)的时候,OPUS 中对判断算法进行了重写,增加了一个 quantoffset 参数并重新规划了量化的范围,这里和 Silk 比较,带来的 MOS 分增益,我自己测的是大约在 0.05 左右(少量样本测试,不一定准确,仅供参考)。
  3. OPUS 的 Delaydecision 模块默认是计算 40 个采样点的总误差,Silk 是 32 个,选择的采样点越多,误差越小,但延时会越大,这两个我试了一下对 MOS 分的影响基本没有,。
  4. 在编码时,OPUS 使用 SHIFT_ROUND 将 Q10 转化成了 Q0 传入到编码模块,Silk 使用的是 SHIFT 方法,两者的不同之处在于,SHIFT_ROUND 会将 [-512,512] 的值都转化为 0,而 SHIFT 的置零区间为 [0,1024],这里使用不同的 SHIFT 算法会影响到后续编码激励时分配的码率。
  5. OPUS 通过调整计算步骤,增加新参数(如 delayedgain 和 diff 等)等方法,减少了少量计算量。

二、编码部分:

  1. OPUS 中的编码模块由依赖Silk中的概率密度函数 CDF 转成了逆概率密度函数 iCDF,尚不清楚做这种改动的原因,从结果上来看,使用 CDF 和 iCDF 的编码效率是差不多的。
  2. OPUS 将编码 index 和 excition 的函数区分开了,但函数的实现及各个参数的编码顺序和 Silk 是相同的,总的来说,这是一个关于模块化的改进。

三、其余部分:

  1. 增益计算部分,OPUS 在较多函数里使用的是 Q7,Silk 使用的是 Q0,因此 OPUS 对增益的控制能稍微准一些。
  2. OPUS 对码率控制算法进行了重写,但总体逻辑和 Silk 是相同的,个人认为 OPUS 的码率控制更为激进一点,压得狠,放的快。
  3. OPUS 的抖动算法中 Seed 的判断方法也改变了,OPUS 中通过判断 Seed 是否小于 0 进行符号的转换,Silk 通过把 Seed 右移 31 位后做异或后自减进行判断,其实这两种方法的结果是完全一样的,只是方式一的计算量更小。

Silk 和 Celt 整合到一起后,经过各方努力,Opus 在 2012 年作为免版税的开源编解码器成为了 IETF 的标准。也就是在差不多那个时候,WebRTC 也成为了 IETF 在 Web 通信上的标准,而 Opus 凭借其卓越的性能成为了 WebRTC 的内置编解码器。一直到今天,Opus 仍在不断发布版本,就在前不久,Opus 发布了 Opus 1.3.1。从发版趋势可以看出,Opus 也在拥抱 AI 化。

目前 Opus 里和 AI 相关的技术有两个:基于 RNN 的语音音乐分类器和一个附加的基于 RNN 的降噪模块(这个降噪模块目前并不在 Opus 本身的代码里,但不排除以后会和 Speex 一样,把信号处理模块耦合进编解码器)。

从 Opus 的诞生和发展历程可以看出,任何产品做到极致都需要付出不懈的努力和漫长的打磨时间,尤其是在创新领域,其路漫漫,道阻且长,各位同学一起加油吧。


欢迎关注编解码器、实时音视频技术的小伙伴访问 RTC开发者社区,与更多同行交流。

编辑于 2019-05-23

文章被以下专栏收录

    在这里会分享RTC实时互联网大会(每年一度全球最大规模的 RTC 技术大会)的干货内容,它们来自全球一线音视频技术专家、WebRTC 资深工程师与资深网络架构师们的演讲。同时,还将分享来自声网 Agora 工程师团队的开发经验。