在上文中我们除了提及的 AAC ，常见的音频编解码格式还有：OPUS、SILK、SPEEX、MP3、iLBC、AMR、Vorbis、G.7 系列等等，而在 RTC 应用中常用的有 AAC 和 OPUS，我们今天将重点了解这两种格式，并会围绕音视频业务开发者关注的：编码方案的优缺点、如何根据场景来灵活选择等维度进行讲述。

如何选择音频编解码格式

在具体介绍 AAC 和 OPUS 之前，先和大家聊聊：如何选择一个合适的音频编解码格式？以及当我们选择音频编解码方案时，我们究竟在 “选” 什么？

从大方向上看，我们选择音频编解码方案时主要考虑两点“可不可用” 和 “好不好用” ，而每个大方向上，会有其细分维度。

首先是“可不可用”。具体的应用场景，可能因为某些“限制”导致某些编解码方式“不可用”或者“仅可用”，这些限制主要涉及“兼容性”和“适用性”两方面。

对于兼容性，就音视频场景来说，主要指流媒体传输协议兼容性和平台兼容性。而平台可能绑定某种流媒体传输协议，二者一般是关联考虑的。比如微信小程序平台支持 RTMP 传输协议，而RTMP 协议支持 AAC 音频编码，就形成了一定制约。另外需要注意的是，如果某两个平台支持的音频编解码格式不同，又有互通需求，可能就需要通过服务端转码的方式来搭建桥梁。

对于适用性，主要指的是“频宽支持是否符合场景需求”。频宽指的是声音频率的支持范围，人耳对声音频率的感知范围（20Hz~20kHz）可以被划分成四个频宽区间：窄带、宽带（wideband）、超宽带（super-Wideband）和 全带（fullband），如下图所示：

结合已学习的声音频率、采样率、奈奎斯特采样定理等概念，大家应该很容易就能理解上述图表。举一个简单的例子，音频编解码格式 G.711 仅支持窄带信号，所以在编码普通语音（低频）时“可用“，适用于固话、电话场景，但是在编码全带信号时“不可用”，不适用于音乐直播等场景。

考虑了“可不可用”这个基本标准后，我们还需要有进一步的追求，那就是 “好不好用”。

某种编解码格式 “好不好用” ，主要指的是：它在满足特定场景基本要求的基础上，能否将编码工作做到“尽善尽美”。而在 RTC 场景下，关于“尽善尽美” 我们主要考虑音质和延迟两方面。

关于音质。音质是大家普遍关注的指标，它的影响因素还比较多，除了已经提到的采样率，还有采样位深和声道数，支持的采样位深越大、声道数越多，自然可以更好的保证音质。比如 AAC 支持 96khz 采样和多达 48 个声道，这让它在追求高音质的场景备受青睐。既然采样率、采样位深和声道数均影响音质，那么基于三者计算的综合指标 – 码率，自然也不例外。一般来说，支持的码率越高、越广，音质越能得到保障、灵活性也越大。那些仅支持固定码率的编码格式，比如仅支持 64kbps 码率的 G.711，其适用范围、音质上限就受到很大的限制了。

关于延迟。延迟在音视频传输中，指的是音视频数据从“主播端麦克风采集“、到从“观众端扬声器播放”的“端到端耗时”，这个耗时由音视频处理链路上的各个环节引入，包括采集、前处理、编解码、网络传输、渲染播放等等。显然，延迟越低意味着实时性越高，也就越接近于“面对面沟通”，在有连麦互动需求的场景中，“低延迟”甚至是最重要的需求之一，关乎用户体验的核心。所以，根据场景需求，选择一个延迟合适的编解码格式相当重要。

综上，当我们选择编解码方案时，我们其实是在选择 “兼容性” 和 “适用性”，进一步的，还需要关注 “音质” 和 “延迟”，通过这四个细分维度，就基本能保证所选方案是”可用“且“好用”的。最后，我们就 RTC 场景下常用的编解码：AAC 和 OPUS，再来对比说明下。

AAC 和 OPUS 的选取

AAC，是基于MPEG-2规范，由 Fraunhofer IIS、Dolby Laboratories、AT&T、Sony 等公司于1997 年合力研发推出，经过 25 年的发展已经被各个领域广泛应用。而 OPUS 由 Xiph.Org、Skype 等基金会研发推出，2012 年才被 IETF 批准进行标准化，相对于 AAC ，OPUS 更“年轻”。关于 AAC 和 OPUS 以及其他常见音频编解码格式的特性对比，有两张图可以很直观的展示，我们直接看图说话。

上图展示了各编码算法的编解码耗时（Delay，纵轴）、支持码率范围（Bitrate，横轴）、支持频宽。

上图展示了不同音频编码在不同码率 （Bitrate）、不同频宽上的音质表现（Quaity）。

不难发现，在罗列的编码算法中，OPUS 格外瞩目，它在 “频宽支持”、“码率支持”、“延迟” 和 “音质”方面，都有比较明显的优势，可以说是“学霸”一个。OPUS 的优势，得益于它集成了两种编码器：语音编码器 SILK、超低延迟的编码器 CELT，并做了很多针对性的优化。它可以无缝调节高低码率，具有极低并灵活可控的算法延迟，并支持全频宽。在实际场景的测试中，OPUS 比 MP3、AAC 等编码有着更低的延迟和更好的压缩率，音质也不甘拜下风。因此，OPUS 在 RTC 场景下备受青睐，某些对端到端延迟极度敏感的场景，更是将其作为必选项，比如实时合唱KTV，多个用户同时上麦K歌，需要依赖极低的端到端延迟来保证同步性。

而反观 AAC，其编解码耗时比 OPUS 高，相对来说不怎么适用于实时互动场景，但它在音质高保真方面，仍然有着不俗的实力，尤其是在极高采样率、高码率、多声道配置下的编码效果尤佳（AAC 最高支持 96kHz 采样率，而OPUS 为 48kHz ，虽然都是全频宽，但是 AAC 在高频部分能保留更多细节），非常适合音乐直播。另外，除了标准规格，AAC 系列还在算法延迟、编码复杂度、编码效率等方面进行针对优化，推出了多种扩展规格，便于我们灵活选择。比如延迟优化版的 AAC-LD（Low Delay），从图一中我们看到其延迟已接近 OPUS；编码复杂度优化版的 AAC-LC （Low Complexity），在中高码率上进一步寻求音质和编码效率的平衡点，并提供更好的兼容性；编码效率优化的 AAC-HE（High Efficiency），进一步提高压缩效率，以追求在更低码率下获得更高的音质。

其实，从上面的介绍来看，各方实际测试数据表明，OPUS 作为一种“年轻”的编解码格式，的确有后来居上、长江后浪推前浪的实力，大部分场景下应该是更优于 AAC 的方案。但胜在“年轻”也输在“年轻”，年仅十岁的 OPUS 和已经二十五岁的 AAC 比起来，还缺少一点“人生经历”和“江湖地位”，别忘了，在“如何选择音频编解码格式”的评估维度中，有一个重要的指标：“兼容性”。

作为前辈，并且背靠 Fraunhofer IIS、Dolby Laboratories、AT&T、Sony 等巨头，AAC 在各领域已得到比较充分的普及，拥有广泛的硬件设备、软件应用和传输协议兼容性，这些都是 OPUS 短时间内无法超越的。比如，RTMP 是直播场景常用的流媒体传输协议，它对于 AAC 编码具有良好的兼容性，却不支持 OPUS 编码，而大部分的 CDN 厂商均默认使用 RTMP 作为推流协议，某些平台比如微信小程序也仅支持 RTMP 传输，为了保证兼容开发、推广效率，我们往往只能选择或优先选择 AAC。

值得一提的是，Google 鼎鼎大名的开源项目 WebRTC 使用了同样开源、免费的 OPUS ，作为其默认的音频编解码方案，但标准 WebRTC 不支持 AAC。这就导致，一些跨平台的音视频应用需要依赖服务端转码来实现与 WebRTC 的互通，转码操作一定程度上增加了传输延迟和开发运维成本。

最后，我们通过表格再整理一下 AAC 和 OPUS 的差别，并在细节上进行适当的补充。