2.4 码流与封装：ADTS、ADIF与MP4

2.4 码流与封装：ADTS、ADIF 与 MP4

本节摘要：AAC 裸流没有帧边界与配置信息，必须靠封装层补齐。本节对比 ADTS（逐帧自描述，为流式而生）、ADIF（全局头一次声明，为文件而生）、MP4/M4A（Box 结构 + 索引，为多媒体生态而生）三种方案的设计取舍，并逐位解析 ADTS 头、说明 Opus 侧的对应物（Ogg/Opus 头与 RTP 载荷）。

算法讲完（2.2、2.3），本节回答"比特怎么组织"：这决定了 AAC 为什么在广播与文件场景互操作顺畅，也解释了 4.3 节生态对比里的一批现象——比如为什么 HLS 切片用 ADTS、音乐商店用 M4A。

为什么裸流不能直接用

编码器输出的 AAC 原始数据块只有语法元素本身，缺三样东西：帧边界（解码器不知道下一个 access unit 从哪比特开始）、配置信息（采样率、Profile、声道布局）、以及与外部系统的衔接点（音视频同步、随机定位、元数据）。封装层就是补这三样东西的协议。设计空间于是被拉伸出三个方向：要"每一帧都自包含"还是"全局声明一次"？要"流式友好"还是"随机访问友好"？要不要承载视频字幕？三个方向的极端答案分别是 ADTS、ADIF、MP4。

图：三种封装的形态对比

ADTS 头：逐位拆一遍

ADTS 头是理解"流式自描述"的最佳标本。7 字节（无 CRC 时）的位域布局如下：

写一个最小解析器最能体会位域的抠法：

typedef struct {
    int profile, sf_index, channels, frame_length;
} adts_hdr;

int adts_parse(const unsigned char *b, adts_hdr *h) {
    if (b[0] != 0xFF || (b[1] & 0xF0) != 0xF0) return -1; /* 同步字 */
    h->profile      = (b[2] >> 6) & 0x03;
    h->sf_index     = ((b[2] & 0x0C) << 2) | (b[3] >> 6);
    h->channels     = (b[3] >> 3) & 0x07;
    h->frame_length = ((b[3] & 0x03) << 11) | (b[4] << 3) | (b[5] >> 5);
    if (h->profile == 0 || h->sf_index > 12) return -2;   /* 非法组合 */
    return 0;
}
​

两个实战细节：同步字匹配后要继续校验 frame_length 与采样率索引的合法性再确认，否则在脏流里会频繁假同步；channel_configuration 为 0 时声道布局藏在帧内 PCE 元素里，解析器必须留这条后路。

MP4 侧的要点与 Opus 对照

MP4 里 AAC 帧剥掉了 ADTS 头，成为纯裸帧存在 mdat 里；解码所需的全部配置集中在 moov 的 esds 中的 AudioSpecificConfig（ASC）——采样率、声道、Profile，以及 SBR/PS 的隐式启用标志。这带来一个经典故障源：同一份裸帧，放在 ADTS 里能播（头里有信息），搬进 MP4 却要靠 ASC 说清；ASC 与实际流不符时表现为爆音或直接解码失败。HE-AAC 的 ASC 还有一个历史包袱——SBR 隐式信令（采样率写法有歧义），不同解析器理解不一，是兼容性事故的高发区。

Opus 的封装对应物值得并排看：文件场景用 Ogg（页结构，头页带 OpusHead 描述声道与预跳过），实时场景用 RTP 载荷（RFC 7587，帧头自带配置）。AAC 需要在"逐帧头开销"与"全局配置"之间做选择题，Opus 的帧设计把配置压进了 TOC 字节，两种场景共用同一套帧语法——封装层面的差异，根源又在帧结构本身（第 3 章展开）。

封装排障的三个实战场景

场景一：直播流随机爆音。现象是 ADTS 流每隔几十秒出现一次爆音后恢复。定位路径：先抓流存档（保存原始字节），写脚本扫描同步字并核对每帧 frame_length 与实际字节间隔的一致性——发现是封包层偶尔在帧边界中间切包，两半各自拼不成合法帧。修复在传输层（按帧对齐打包），不在编码器。这个手法（同步字扫描 + 帧长核对）是 ADTS 排障的万能起手式，二十行脚本以内。

场景二：M4A 在部分播放器无声。同一文件，专业播放器正常、某批嵌入式播放器无声。定位：对比 esds 中的 ASC 字段与实际码流特征，发现 ASC 声明的声道布局与帧内实际元素不一致（封装工具的旧版本写入了一个非标准组合）。修复：重封装写入标准组合。教训：MP4 播放失败时，先 dump ASC 逐字段核对，再怀疑内容本身——"头说一套、流说另一套"是封装层的经典病灶。

场景三：Opus 文件时长显示错误。Ogg 封装的头页 OpusHead 里的预跳过（pre-skip）样本数没被某播放器计入，导致首帧丢失感与时长偏差。这类问题提示我们：容器头的每个字段都有语义，跳过它们做"傻瓜式"封装，迟早会在某个较真的播放器上翻车。给自己的封装工具写单元测试（构造已知流、断言头字段）是值得的一次性投入。

三个场景的共同教训：封装层的 bug 表现得像编码器的 bug（爆音、无声、时长错），排障时"先验身份再查内容"的顺序能省一半时间——这正是本节把封装单独成节的用意。

💡 关键直觉：封装是编码器的"外交辞令"。ADTS 逐帧自我介绍（适合萍水相逢的流），ADIF 开场自我介绍（适合从头认识的文件），MP4 靠中间人索引（适合复杂社交圈）。排障时先分清层——同步丢失查封装头，解码失败查 ASC/Profile 一致性，音质问题才回到 2.2、2.3 的算法层。

本章最后一节回到延迟主线：AAC-LD 与 ELD 如何为实时场景补课，补到了什么程度——那里也是 Opus 的主场开赛处。