【经验分享】RTC技术系列之音频编解码

总体来看，通讯发展经历了几个阶段-消息(电报)-语音通话-视频通话-AR/VR，当然声音在其中是少不了的，即使在视频和AR/VR阶段，都需要有声音的交流，总不能视频上光白活没声音吧。本文就分享一下在实时通讯领域音频编解码的一些经历和经验。

音频编解码其实有很多种，在不同领域有不同的应用，要理解这个首先要从人说话和人耳朵听到声音的频谱范围说起，人说话的声音频谱能量范围大部分分布在300~3400HZ，而人耳能听到声音的频谱范围一般为20~20000HZ，所以人耳是可以听到除人说话外的自然界的很多其他声音的，像乐器，自然界，尖鸣声等等。当然每个人都会不太一样，B站上有个可以测试自己听觉范围的，链接在下面，大家可以去试试(当然高频的时候如何有任何不适，本人概不负责)。

https://www.bilibili.com/video/BV1Xs411s7qo?from=search&seid=12278321081543626393

同时科学界奈奎斯特定理表明，通过2倍于最高频率进行采样的，就可以完整的还原模拟信号。了解了这两个原理后，下面对音频编解码的应用就可以比较好的理解了。

人说话的声音经过数字采样后，即为PCM原始采样数据，从图中可以得知，不过什么编解码类型，都是将PCM编码压缩方便传输，然后再解码恢复成PCM的过程。

首先看在早期的固定电话时期，固话时期的编解码主要有G.711a/u；G.729；G.722；G.723；G.726等等；这些编解码基本都是使用8KHZ的采样的，由于当时的通讯只是主要是人与人之间说话，8K采样率足以覆盖人说话声音的最主要部分能量范围了。最初的G.711a/u属于无损编码，但是由于要64Kbps的速率(但是ADSL电话线的速率也就是64K带宽)。

不知道还有多少朋友知道ADSL上网，最初就是用这64K的电话线传输，但是G.711把带宽占光了，还怎么传输数据呢，因此后续逐渐被压缩率更高但是效果也不逊色的G.729，G.726等编解码取代使用。其中G.722属于比较出名的一个系列，G.722.1是polycom研发的编解码，而G.722.2就是AMR-WB+，下面提到的AMR-WB的超宽带版本。

当然到了3G/4G时代，随着互联网的发展，基于互联网的VOIP技术也蓬勃发展起来，但是基于互联网的VOIP比运营商语音通话面临着更加严峻的复杂网络情况，毕竟不是专网，因此面临的延时带宽问题更加严峻。VOIP的音频编解码也存在类似的发展阶段，首先是语音编解码，像iLBC和iSLK，这两种编解码都是GIPS公司开发的编解码技术，被Google收购后，两种编解码技术就用应用在WebRTC技术中并且开源了，ILBC编解码的特点是减少每个音频编码帧之间的冗余性，每帧独立可解，因此具备了很不错的抗丢包特性。ISAK我了解的不多，除了继承ILBC能力之外，好像是增加了带宽预测功能。红极一时的Skype使用的编解码则是silk，silk编解码对于语音有特别好的编码效果，据说可以使得通话双方听起来像双方在同一个房间里一样(silk源码原来在skype开发者网站开放的，不过网站现在无法访问了，可以到github上找下声网技术VP高大神共享上传的源码https://github.com/gaozehua/SILKCodec)

大名鼎鼎的WebRTC为了提升语音体验，默认使用的编解码就是Opus(silk编解码和celt编解码的组合)；此编解码器内一个Music detector去判断当前帧是语音还是音乐，语音选择silk，音乐选择celt(这款编解码我确实不太熟悉，不过据说高频领域比AAC弱一些)；同时opus支持PLC(丢包补偿)，具备较好的网络抗丢包特性。其实大家可以看到，WebRTC在google一直是走开源策略，如果不开源，google是不会使用的，像H.264因为不开源，google就另行开发了VP8，VP9，这个在后续的视频编解码里再探讨。

其实音频也不只在通讯领域使用，像AAC(Advanced AudioCoding（高级音频编码）)，是一种由MPEG-4标准定义的有损音频压缩格式，由Fraunhofer发展，Dolby, Sony和AT&T是主要的贡献者。在使用MP4作为各种内容的容器格式的新多媒体MPEG-4标准中，它是MPEG Layer III / MP3的天然后继者。AAC编解码跟Mpeg4的视频编解码协议类似，也分为多Profile，LC-AAC(低复杂性)和HE-AAC(高效性)，个人理解就是消耗CPU少和压缩率更高。

当然说到RTC技术，肯定要提到声网Agora，Agora在19年RTC大会上也开源了自研的编解码协议SOLO。SOLO应该是以Silk为基础，融合带宽扩展(BWE)和多描述编码(MDC)技术，打造出的一款不稳定网络下抗包出众的编解码，至于具体实现我就要去GitHub上学习了。

最近验证使用Agora的RTSA-Lite的SDK库，按照API接口文件描述，支持这四种编解码。可以看出其选择还是很有针对性的，opus可以无缝的和WebRTC对接；G722可以适应与移动端通讯；而两个AAC系列可以利用在音乐音质要求比较高的领域。(不知道为什么没有SOLO？)

最后，随着5G时代的到来，随着内容业务百花齐放，除了通话/音乐外，相信适用于新场景的音频编解码技术也会得到快速发展。像VR技术，就需要3D沉浸式的音频技术，像大家都知道的杜比全景声技术，像object based audio和ambisonics技术；随着网络带宽不再是问题，音频编解码应该不会再区分音频和音频了，融合是趋势；所谓体验无止境，从而音频编解码技术也无止境。

其实作为业务开发者，我觉得应该了解的是编解码的特点，结合你所在领域的业务特点，以及业务所处网络，带宽，丢包等等因素，已经编解码所在硬件的处理能力(内存/CPU/协处理器)，从而可以做出正确的选择，初期我们是把这项技术应用在业务领域为客户提供好的体验(毕竟这个领域的大大神们研究了这么多久，我们没必要从信号采样再研究起)；对于编解码内核的频域转换/滤波等原理性技术可以随着业务的发展，当然结合自己的能力，再逐步加深学习。

本文为个人原创，首发于 声网开发者社区[https://rtcdeveloper.com/t/to...]