呈现一个更好的 HLS 音频体验

（你好 WWDC 2020） 你好 欢迎来到 WWDC （呈现一个更好的 HLS 音频体验） 大家好 希望大家喜欢本次大会 如果大家想要提升数据效率 同时提升 HLS 音频流的保真度 看这个演讲就对了 我叫 Simon 我是 Apple 的流媒体工程师 在这个演讲中 我们将会一起探索 如何打造更好的 HLS 音频体验 在开始之前 我要为大家提供 一些额外的指导 它们对 Apple 设备 HLS 现有的编写规范是一种补充 在 developer.apple.com 可以查看这份说明文档 我建议大家在观看这个演讲之前 先熟悉文档中的内容 如果有需要的话 大家可以暂停视频 因为这个是点播视频 先去看文档 先熟悉文档中的建议 然后再回来看视频 多余的话不说了 我们现在就开始吧 今天我们会谈到两个话题 第一个话题 我会向大家介绍 3 个新音频编解码器 它们在 2020 年 发布的 OS 中新加入 HLS 然后我会跟大家谈谈 在多声道配置中如何利用 其中的两个编解码器 让我们来探索在 2020 年发布的 OS 中 新推出的音频编解码器 第一个是 xHE-AAC 它表示扩展高效进阶音频编解码器 这一串形容词都是为了提示大家 这个音频编解码器 在中低码率的情况下非常高效 比如低于 200kbps 时

在 2020 年发布的 OS 中 另两个音频编解码器 都是无损音频编解码器 它们分别是 FLAC 即自由无损音频编解码器 以及 Apple Lossless 无损编解码器 在 2020 年发布的 OS 中 xHE-AAC 是新的 HLS 编解码器 但在 2019 年发布的 OS 中 即 iOS 13 和 macOS Catalina 它已经可以用于基于文件的回放 而 FLAC 和 Apple Lossless 在很早以前就能支持基于文件的回放了 让我们来谈谈第一个编解码器 xHE-AAC xHE-AAC 在 MPEG-D 标准中还有个名称 那就是 USAC 它代表语音音频统一编码 这个名字提示了大家 它还是一个 专门为语音回放优化过的编解码器 它还是非常优秀的通用型音频编解码器 特别是针对中低码率而言 这一点我在前面已提过 下面我们把 xHE-AAC 和 AAC 编码家族进行整体性的比较 它们之间稍有不同 AAC 编解码器家族中 首先是大家都熟悉的 AAC-LC 它代表进阶音频编解码器-低复杂性 我们建议 在低至 96kbps 的低码率情况下 使用这个编解码器

我们用编解码器属性的 ISO 句法 识别这个编解码器 即 mp4a.40.2

这个编解码器进化成了另一个编解码器 即 HE-AAC 即高效进阶音频编解码器 它之所以能够进化是因为 它添加了额外的 SBR 编码工具 SBR 表示频段复制 它通过核心 AAC 媒体编码中的 已有低频段数据 来重建高频段 我们建议在低至 48kbps 这样的低码率情况下使用 HE-ACC

你可以使用 mp4a.40.5 编解码器字符串 来识别 HE-AAC

但到这里还没有结束 它升级到了 2.0 版本 即 HE-AAC v2 它添加了另一个编码工具 称为参数立体声 参数立体声从单声道音频中 使用一些额外的参数数据 重建出另一声道 我们建议在码率低至 32kbps 的情况下 使用 HE-AAC v2 编码互通性到此告一段落 这 3 个音频编解码器之间 具有一定程度的互通性 你们可以用 HE-AAC 解码器 解码 HE-AAC v2 编码 不过当然 在此强烈提醒 你们只能得到一个单声道音频 因为早期编解码器 不知道如何处理参数立体声

让我们来看看 xHE-AAC 的特点 xHE-AAC 不向下兼容 它仍保留前述的编码工具 或者编码工具高度相似 但它们都更加进阶 它们经过优化 效率更高 因此在你们的主播放列表中 正确识别 xHE-ACC 非常重要 它的编解码器属性 ISO 语法 是 mp4a.40.42

这是一个先进的编解码器 效率非常高 我们建议在码率低至 24kbps 的情况下使用它 xHE-AAC 和其余 AAC 家族编解码器 另一个区别是 标准化机构处理它的方式 我们一向在 HLS 编写指南中建议 加入响度 和 DRC 元数据 DRC 指动态范围控制 什么是动态范围控制？ 它是额外的元数据 可以让媒体系统 持续调整音频讯号电平 以减少高响度和低响度之间的音量差异

我们一直推荐大家加入这些元数据 或者确保你们的节目内容 以及其中的任何插播内容 均将音量均衡化到相同水平 我们的建议和美国国家标准学会的 ANSI/CTA-2075 新标准一致 该标准也有一些有用的文本信息 建议加入该元数据

另一个标准与该做法不同 并且实际上它在做法上更进一步 它就是 CMAF CMAF 的含义是通用媒体应用格式 该格式旨在统一 MPEG-DASH 和 HLS 之间的媒体编码 它的更进一步体现在 它强制要求你们的媒体编码 加入该元数据

对于其它 AAC 家族编码 CMAF 仅是推荐加入该元数据 所以重点是 DRC 正在音频产业内 变得越发重要 而你们加入该元数据 就是走在前进的道路上 我们来看看 HLS 要怎样 在 Apple 设备上支持 xHE-AAC 我前面提到 使用 xHE-AAC 有一点很重要 那就是通过编解码器属性 声明对它的使用 再次强调 其句法是 mp4a.40.42 AVPlayer 来自 AVFoundation 框架 它支持单声道和立体声配置 目前还没有多声道支持 其承载数据方式仅限于 片段 MP4 容器类型 唯一支持的加密机制是通用加密 那么要如何在你们的软件和服务中 充分利用 xHE-AAC 呢？ 首先我要重申一下 这种编解码器非常适用于 从低至 24kbps 码率 到高至我们推荐的 AAC 最高码率范围内的立体声音频 这个最高码率为 160kbps

而在你们的软件和服务中 利用 xHE-AAC 的最简单办法 是在你们的主播放列表内 加入额外的低比特率音频分支 这么做的动机有两点 一 你们想覆盖到使用低速网络的客户 低速网络 或者会导致他们 发生卡顿的其他情况 二 为了覆盖到以下客户 他们的设备由于具有多种网络连接性通路 而带有设备数据速率限制 比如 Apple Watch 就属于这种设备 我们另有一场演讲 题为 《Apple Watch 的流媒体创新》 我建议你们去看一看 但我这里就有个例子 假设你们有一个现成的主播放列表 它在你们的内容库里 声明使用两种音频分支 第一个音频分支使用 HE-AAC 码率为 48kbps 播放列表第二个音频分支使用 AAC-LC 码率是 64kbps 为了覆盖到低速网络的客户 防止他们在回放过程中卡顿 又为了覆盖到使用了 具有数据速率限制的设备的客户 你们只需要加入一个新的分支 使用 xHE-AAC 并正确声明它的编解码器字符串 这样你们就有了一个 24kbps 的分支

还有些其他的方法 可以让你们在软件和服务中 使用 xHE-AAC 第一种方法是可以 让你们的部分或全部 AAC 编码 或其衍生编码与 xHE-AAC 并行传输 这么做的动机在于提供高质量的音频分支 并维持相同的给定码率预算

另一种使用该编解码器的方法 就是把它作为给你们的播放列表 引入 DRC 支持的机会 把你们的内容库迁移到 DRC 越来越重要的未来标准 你们可能会想问 如何强制 AVPlayer 选择高保真音频分支 而不是现存的音频分支呢？ 答案是我们为字符串标签 引入了一种新的属性 名为 SCORE 属性 我们在另外一个演讲中 详细介绍了该属性 该演讲名为 《使用 HLS 工具改进的串流制作》 我建议你们去看一看 不过我这里有个例子 这个例子里 我有两个音频分支 第一个音频分支声明为 xHE-AAC 其码率声明为 94kbps 我还有第二个音频分支 是 AAC-LC 码率 96kbps 我用 SCORE 为 xHE-AAC 评出 比 AAC-LC 更高的分数 你们可能还会注意到 xHE-AAC 分支使用的带宽 比 AAC-LC 分支要少 使用 SCORE 属性 AVPlayer 就会在支持的情况下 偏好选择 xHE-AAC 分支

现在我们来说说无损音频 我提过 新的音频编解码器 是 FLAC 和 Apple Lossless 两者都是开源的 但它们各有所长 FLAC 在业内使用更加广泛 而 Apple Lossless 能在 MPEG-4 中 实现更稳定的承载 HLS 打算如何在 Apple 设备 2020 年发布的 OS 中支持无损音频呢？ 我们需要先正确地声明对它的使用 再强调一次 我们声明它的使用时务必要 使用编解码器字符串 fLaC L 和 C 要大写 请遵守这个奇怪的写法 对于 Apple Lossless 写法则是 alac AVFoundation 框架内的 AVPlayer 支持这两种编解码器的 所有的声道配置 至多可达 8 声道 稍后我们详细说这一点 承载方式仅限于使用片段 MP4 容器类型 唯一支持的加密机制是通用加密 那么你们如何在自己的软件和服务中 充分利用无损音频呢？

第一种方法就是把额外的高码率音频分支 加入播放列表 你们只有在清楚了解 客户带宽充裕时才应该这么做 此外也只有在你们的客户 期待极高的音频保真度时 才应该考虑这么做 我们现在进入本次演讲的第二个话题 看一看我们要如何在多声道使用情况下 使用这些无损音频声道 我前面提到 FLAC 和 Apple Lossless 支持多达 8 个声道 也就是支持 5.1 和 7.1 这样的声道配置 有一点要注意 两种编解码器的声道布局是有微小不同的 如果想让声音从正确的扬声器播放 请务必遵守正确布局 Apple Lossless 最先排列的是中置声道 然后是左声道和右声道 而 FLAC 需要先放置左声道和右声道 然后才是中置声道 现在你们可能已经明白 无损音频需要极高的数据速率 其远超过我们习以为常的 有损音频编解码器 比如 AAC 但是需要多少呢？ 如果我要向你们展示 FLAC 比 AAC-LC 要多占用多少码率 我的图表就必须腾出更多的空间 我的 Y 轴必须要修改 稍等 我马上就改好

好了 改好了 AAC-LC 48kHz 采样率 它的码率仍然是 160kbps 但现在我修改过图表之后 它显得非常小 这样我就有充足的空间来介绍无损音频 无损音频同等情况几乎要大四倍 在 16 位精度 48kHz 采样率下 码率接近 1Mbps 在更高端情况下 采用 24 位精度 以及 96 kHz 采样率时 码率被抬到了几乎 3Mbps 但这还没完 你们能看到 AAC 这样的有损编解码器 可以由你设定编码器 输出指定目标比特率的编码 但无损音频编码器不能这样 它们自行决定需要的数据量 以打造你们要求的音频保真度 所以这些都是平均的码率 加上峰值码率才完整 现在 看看和 AAC 最接近的音频保真度 16 位精度 48kHz 采样率下 码率超过 1Mbps 多声道情况下与此相似 请注意 Y 轴现在变化了 而 AAC-LC 的码率现在是 400 kbps 无损编码中与其最接近的码率 已超过 2Mbps 高端情况下 码率达到了 8Mbps 其精度为 24 位 采样率 96kHz 且包括 6 声道音频 所以我们务必要考虑到 如何自适性地提升到 这些极高的比特率

而我们推荐的做法是 在你们的主播放列表中加入多声道 AAC Apple 软件包的 Compressor 可以对其进行编码 但关于多声道 AAC 有一点需要注意 就是它在不同的 Apple 设备之间 拥有的支持程度不同 它不能实现全声道的完整解码 在不能实现全声道完整解码的设备上 你们会得到双声道 或者立体声 但要注意 这并不等于我们不需要遵守 加入立体声 AAC 以实现向下兼容的要求 我用一个例子演示一下 这是一个播放列表 媒体标签在最上面 它们声明了声道数量 我们把它先去掉 因为它无关我们现在的讨论 高亮选中的分支就是可供回放于 支持完整解码多声道 AAC 设备的 音频分支 假设我们使用这样的设备 且该设备有一条音频路由 可以渲染多声道音频 我们可以自适性地从 HE-AAC 多声道 提升到 AAC-LC 多声道 一直提升到 2Mbps 的无损多声道 对于立体声也是同理 我们可以从低码率的立体声 AAC 开始自适性地提升到 高码率的立体声 AAC 再自适性地提升到完整 1Mbps 的 无损立体声音频 现在假设我们去掉播放列表的多声道 AAC 我并不推荐这么做 请不要在家模仿 这是同样的播放列表 其中去掉了多声道 AAC 这次我的媒体标签还是在上面 我直接把它们去掉

那么如果我们使用的 是支持多声道输出的设备 它的当前音频路由支持多声道渲染 有一条音频分支可用于回放 它是无损音频分支 需要 2Mbps 的数据速率 如果你们的客户无法维持 2Mbps 的速率 那你们的回放或他们的回放就会卡顿

而因为我们强制在所有播放列表中 加入了立体声 AAC 对立体声的播放仍然会自适性地提升 从低码率 AAC 提升到高码率 AAC 一直提升到无损立体声 我们学到了很多东西 我们来总结一下学到的内容 我介绍了三种新的音频编解码器 我们谈到了在你们的媒体编码之中 加入 DRC 的必要性 这对于未来产业的发展很重要 我们还谈到了 使用多声道无损音频的考虑因素 以及利用多声道 AAC 作为提升至这些极高码率的手段 那么当你们回到家 应该做什么呢？ 也许你们已经在家里了 那么考虑一下如何部署 xHE-AAC 以满足使用低速网络客户的要求 然后考虑如何使用这种编解码器 更好地利用他们现有的网速 以呈现更佳的音频保真度

另外一定要考虑 如何在可行的情况下 让你们的软件或服务 使用无损音频编解码器 希望大家收获满满 并喜欢大会的其它部分内容 最后 祝大家回家时一路平安 哪怕只是去隔壁房间也一样