WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Deliver a better HLS audio experience

Deliver a better HLS audio experience

WWDC 2020HLSAudio & Video
观看原视频

Highlight

Apple 在 2020 OS releases 为 HLS 增加 xHE-AAC、FLAC 和 Apple Lossless 支持，并要求作者用正确的 CODECS、DRC metadata、SCORE 与多声道 AAC 阶梯改善低带宽和高保真音频播放。

核心内容

HLS 音频以前很容易卡在两个极端。低带宽网络需要更省流量的编码，否则播放会停顿；高保真内容又需要无损音频和多声道输出，否则用户听不到内容制作时保留的细节。只在 master playlist 里放几条 AAC variant，已经不能覆盖这些场景。

这场 session 给出的第一组变化，是 2020 OS releases 里的三个 HLS 新音频 codec：xHE-AAC、FLAC 和 Apple Lossless。xHE-AAC 面向低到中等码率，Apple 建议最低可到 24 kbps；FLAC 和 Apple Lossless 面向无损音频，AVPlayer 支持最高八个声道，但码率会从接近 1 Mbps 扩展到多声道高规格下的数 Mbps。

这些变化把问题推回 authoring 阶段。你要在 playlist 里写对 CODECS，为 xHE-AAC 带上 loudness 和 Dynamic Range Control（DRC，动态范围控制）metadata，用 SCORE 让播放器优先选更合适的 variant，还要在多声道无损音频前放入多声道 AAC。否则，支持新 codec 的设备拿不到好音质，带宽不足的设备也没有平滑降级路径。

这不是播放器端一个开关能解决的事。服务端编码、fragmented MP4 容器、common encryption、声道布局和 master playlist 的组合，都会影响 AVPlayer 最后选中哪一条音频流。

详细内容

1. 用 xHE-AAC 补上 24 kbps 低码率 variant

（01:33、05:16、07:16、09:01）xHE-AAC 也叫 USAC，面向 speech 和 general-purpose audio。Apple 明确给出 codec string mp4a.40.42，并建议它覆盖到 24 kbps 这一档。演讲里的例子是在已有 HE-AAC 48 kbps 和 AAC-LC 64 kbps 之外，新增一条 xHE-AAC 24 kbps variant。

下面是根据 transcript 重构的占位映射，非 Apple 原始 playlist 片段，只保留演讲支撑的 codec string 和码率关系。

xHE-AAC -> CODECS: mp4a.40.42 -> 24 kbps variant
HE-AAC  -> CODECS: mp4a.40.5  -> 48 kbps variant
AAC-LC  -> CODECS: mp4a.40.2  -> 64 kbps variant

关键点：

  • mp4a.40.42 必须用于 xHE-AAC variant 的 CODECS 属性，因为 xHE-AAC 没有 AAC 家族早期 codec 那种向后解码能力。
  • mp4a.40.5 对应 HE-AAC，演讲中给出的推荐下限是 48 kbps。
  • mp4a.40.2 对应 AAC-LC，演讲中用 64 kbps 作为已有 variant 示例，并回顾了 AAC-LC 可低至 96 kbps 的推荐。
  • 24 kbps xHE-AAC 的作用是给低吞吐网络和 Apple Watch 这类网络路径受限设备留一条可播放路线。
  • AVPlayer 对 xHE-AAC 的 HLS 支持限于 mono 和 stereo，封装限于 fragmented MP4，加密限于 common encryption。

2. 用 DRC metadata 和 SCORE 管住音量与选择顺序

（05:44、10:28）Apple 一直建议在 HLS 音频里包含 loudness 和 DRC metadata。xHE-AAC 让这件事更重要：CMAF 对 xHE-AAC 要求包含这些 metadata，ANSI/CTA-2075 也建议加入。DRC 让系统能持续调整信号电平，减少响亮段落和安静段落之间的差异。

同一段码率预算下，xHE-AAC 可能比 AAC-LC 更适合播放。为了让 AVPlayer 在支持 xHE-AAC 的设备上优先选择它，session 提到可在 stream tag 上使用 SCORE。transcript 只支撑下面这个选择关系，没有给出具体分值或 URI。

xHE-AAC: 94 kbps, CODECS mp4a.40.42, SCORE 高于 AAC-LC
AAC-LC:  96 kbps, CODECS mp4a.40.2,  SCORE 低于 xHE-AAC

关键点：

  • 94 kbps 和 96 kbps 对应演讲里 xHE-AAC 与 AAC-LC 的对比。
  • SCORE 是 HLS variant 上的浮点数；播放器在过滤出可播放 variant 后，用更高的分数决定优先级。
  • xHE-AAC 的码率低于 AAC-LC，但更高的 SCORE 会让支持它的 AVPlayer 优先选择这条 variant。
  • 不支持 xHE-AAC 的设备仍然可以回落到 AAC-LC variant。
  • DRC metadata 属于编码输出的一部分，不能只靠 playlist 属性补齐。

3. 用 FLAC 和 Apple Lossless 交付无损音频

（11:44、12:03、12:54）2020 OS releases 还给 HLS 增加了 FLAC 和 Apple Lossless。FLAC 的 codec string 是大小写特殊的 fLaC，Apple Lossless 是 alac。AVPlayer 支持两者的所有声道配置，最高八声道，封装同样限于 fragmented MP4，加密限于 common encryption。

下面是 transcript 支撑的无损音频事实表，非完整 playlist entry。

FLAC codec string: fLaC
Apple Lossless codec string: alac
Stereo lossless at 16-bit / 48 kHz: average data rate close to 1 Mbps

关键点：

  • fLaC 的大小写要保持这个形式，演讲专门提醒它看起来奇怪但确实如此。
  • alac 表示 Apple Lossless。
  • 16-bit、48 kHz 的 stereo lossless 平均码率接近 1 Mbps，已经远高于常见 AAC 音频 variant。
  • lossless codec 不能像有损 codec 那样配置一个固定 target bit rate；它会按音频保真度消耗需要的数据量。
  • Apple 建议只在用户带宽充足并且确实期待高保真音频时加入这些高码率 variant。

4. 多声道无损前面要有多声道 AAC

（13:28、16:00、17:44）FLAC 和 Apple Lossless 支持 5.1 与 7.1。两个 codec 的声道布局不同：Apple Lossless 要 center channel 在前，然后才是 left 和 right；FLAC 要 left 和 right 在前，然后是 center。声道顺序错了，声音会从错误的扬声器出来。

多声道 lossless 的码率上升很快。演讲给出的对比是：多声道 AAC-LC 约 400 kbps，而 16-bit、48 kHz 的多声道 lossless 已经超过 2 Mbps；24-bit、96 kHz、六声道可到 8 Mbps。Apple 的建议是在 master playlist 里加入多声道 AAC，让播放器能从较低码率逐步扩展到多声道无损。

下面是 transcript 支撑的占位结构，非原始 playlist：media tags 需要声明 channel 数，playlist 需要同时保留 stereo AAC、多声道 AAC 和多声道 lossless 的阶梯。GROUP-ID、NAME、URI、AUDIO 和具体 variant 路径需要由实际服务命名，transcript 没有给出字面值。

media tag: declares channel count
stereo AAC fallback: required for backwards compatibility
multichannel AAC-LC ladder: about 400 kbps
multichannel lossless ladder: over 2 Mbps at 16-bit / 48 kHz
high-end six-channel lossless: up to about 8 Mbps at 24-bit / 96 kHz

关键点：

  • media tag 声明 channel 数，多声道设备才能完整解码到所有声道。
  • 多声道 AAC 阶梯让带宽不足的用户仍然留在多声道路线。
  • 多声道无损阶梯适合带宽和输出设备都满足条件的场景。
  • stereo AAC 仍然要保留，因为 Apple 要求 playlist 包含 stereo AAC 作为向后兼容路线。
  • 如果省略多声道 AAC，支持多声道输出的设备可能只剩一条 2 Mbps 以上的无损 variant 可选，用户带宽撑不住时播放会 stall。

核心启发

1. 给播客和有声书加低网速兜底

做什么：为每个节目新增 24 kbps xHE-AAC audio-only variant。

为什么值得做：session 明确说 xHE-AAC 适合 speech reproduction，并且可用于低到 24 kbps 的数据率。

怎么开始：用 fragmented MP4 输出 mono 或 stereo xHE-AAC，写入 CODECS="mp4a.40.42"，保留 AAC-LC 或 HE-AAC fallback，并在编码阶段加入 loudness 与 DRC metadata。

2. 给 Apple Watch 单独准备音频阶梯

做什么：为手表端 HLS manifest 加入 xHE-AAC，同时保留 AAC-LC、HE-AAC 或 HE-AAC v2。

为什么值得做：session 把 Apple Watch 作为 data rate constricted device 的例子，相关 session 也建议 watchOS 7 音频流使用 xHE-AAC。

怎么开始：把 24 kbps 到 160 kbps 的 xHE-AAC variant 放进 watch 可访问的 manifest；对旧设备保留 AAC fallback；用真实 Apple Watch 网络条件测试 variant 选择和 stall 行为。

3. 为高保真订阅档提供无损 HLS

做什么：在音乐、演出录音或课程音频里加入 FLAC 或 Apple Lossless variant。

为什么值得做：session 给出 FLAC 和 Apple Lossless 的 HLS 支持范围，适合用户明确期待高音质且带宽充足的服务。

怎么开始：先做 stereo lossless，使用 fLaC 或 alac codec string，封装为 fragmented MP4；上线前评估平均码率和峰值码率，因为 lossless 不能设定固定 target bit rate。

4. 做家庭影院场景的多声道音频阶梯

做什么：为 5.1 或 7.1 内容同时提供多声道 AAC 与多声道 lossless。

为什么值得做：Apple 明确建议用 multichannel AAC 作为通向高码率 multichannel lossless 的自适应阶梯。

怎么开始：按 codec 要求整理声道顺序，给 EXT-X-MEDIA 写入 CHANNELS，保留 stereo AAC fallback，再验证支持多声道输出和只支持 stereo 的设备各自会选中哪条 variant。

5. 把 playlist 检查放进发布流程

做什么：在每次音频编码发布前检查 CODECS、CHANNELS、SCORE、DRC metadata 和容器限制。

为什么值得做：这场 session 的核心风险都来自 authoring：codec string 写错、DRC 缺失、声道阶梯缺失，都会让 AVPlayer 无法按预期选择音频流。

怎么开始：在 CI 里扫描 master playlist，确认 xHE-AAC 使用 mp4a.40.42，FLAC 使用 fLaC，Apple Lossless 使用 alac；再用 HLS authoring 工具验证 fragmented MP4、common encryption 和 audio group 组合。

关联 Session

评论

GitHub Issues · utterances