2.5 低延迟补课：AAC-LD与AAC-ELD

2.5 低延迟补课：AAC-LD 与 AAC-ELD

本节摘要：AAC-LD 把帧长从 1024 砍到 512、去掉前瞻，算法延迟约 20 ms；AAC-ELD 再压到约 15 ms。本节算清这两条支线的延迟账与效率代价，说明它们在实时通信版图上的真实位置——以及为什么 FaceTime 选了 ELD 而 WebRTC 选了 Opus。

第二章的收束节：前面四节都在 AAC 的主场（分发）展开，本节让它走进考场（实时交互）。这一步走得吃力与否，恰好为第 4 章的延迟对比提供了 AAC 侧的完整数据。

先把"算法延迟"的定义钉死

算法延迟指编码器结构本身要求的最小时间窗：编码端必须攒够一帧样本、加上变换窗的重叠部分、加上任何前瞻，才能产出第一比特。它不含网络、不含缓冲策略、不含操作系统调度，是压不掉的结构性下限。对帧驱动编码器有一个直接算法：

算法延迟 ≈ 帧长 + 前瞻样本数 + 由重叠带来的额外等待，折算成时间即除以采样率。

AAC-LC 的账：1024 样本帧约 21.3 ms（48 kHz），MDCT 重叠与前向滤波器组需求再加约 5.3 ms，合计约 26.6 ms；HE 系还要叠加 SBR 参数提取的额外缓冲，奔 30 ms 以上。注意这只是编码侧——解码端还有对称的窗等待。分发场景对这几十毫秒毫无感觉，通话场景却要把它放进"端到端预算"里精打细算。

LD 与 ELD 各砍了什么

AAC-LD（约 2000 年，MPEG-4 修正案）的手术很直接：帧长 1024 降到 512（10.7 ms），窗型简化、去掉编码器前瞻。算法延迟落到约 20 ms。为弥补短帧带来的压缩效率损失，LD 重新启用了帧间预测（MAIN Profile 里那件被 LC 抛弃的工具）——稳态内容靠预测增益找补比特。

AAC-ELD（2007 年前后）继续压：帧长 480 样本（10 ms），改用低重叠的专用窗设计（准正弦类窗族），把重叠开销也削掉一块，算法延迟到 15 ms 上下，并配套 ELD 专用的增强版预测与量化工具。ELD 还有 AAC-ELD v2（后继增强），在立体声场景引入参数化工具进一步压码率。

图：延迟谱系对照

补课的代价：效率让渡

延迟不是白拿的。512/480 样本帧的频率分辨率只有长窗的一半，预测工具的引入又提高了对信号平稳性的依赖，同码率下 LD/ELD 的音质普遍低于 LC 一到两档。业内常用的口径是"LD 在 64 kbps 的质量约相当于 LC 在 48 kbps 上下，ELD 还要再让一点"。电话语音（当时仍是窄带思维）能接受这个交换，但面对 Opus 在同码率区间的表现，LD/ELD 的性价比就被压得很薄——这也解释了为什么 LD/ELD 的实际部署高度集中在苹果生态（FaceTime 音轨使用 ELD），而开放的实时通信世界几乎清一色选择了 Opus。

两条路线的对照到此可以立起来了：

一行命令可以直观验证 ELD 与 Opus 在低延迟档的行为差异：

# 同一段语音，ELD 32k 与 Opus 32k（低延迟帧长）
ffmpeg -i speech.wav -c:a libfdk_aac -profile:a aac_eld -b:a 32k eld32.m4a
opusenc --bitrate 32 --framesize 10 speech.wav opus10ms.opus
# 对比两点：文件尺寸的稳定性（ELD 帧大小近乎恒定）与
# 解码端首包出声时间（Opus 短帧显著更快）
​

ELD 的工程细节与一个真实部署的延迟账

ELD 的低重叠窗设计值得多说两句。传统 MDCT 的完美重构依赖 50% 重叠的窗函数对（相邻窗平方和恒为一），ELD 改用低重叠窗族后这个约束放松，代价是窗间不再是完美重构——标准用"足够好"的重构精度换取重叠区样本数的下降。这带来一个实现侧的连锁反应：ELD 对窗系数的量化精度更敏感，不同实现之间的听感差异比 LC 档更明显，选型时要用目标端的实际解码实现做听感验收，而不能只看标准符合性。

把 FaceTime 这类真实部署的延迟账拆开看（量级示意）：采集与前处理约 15 ms、AAC-ELD 编解码算法延迟约 15 ms、打包与系统音频栈约 10 ms、网络单程 20 至 60 ms、抖动缓冲 20 至 40 ms、播放缓冲约 5 ms——合计落在 85 至 145 ms 区间，正好压在对话体感红线内。注意编码器只贡献了总账的一成多；苹果生态敢用 ELD 的底气，一半来自编码器本身，另一半来自它对整条音频栈（系统级低延迟音频通路）的自控力——这印证了 4.1 的结论：延迟是链路属性，编码器只是其中一段。

对照 Opus 在同类链路的账：算法延迟 7.5 ms（20 ms 帧）可比 ELD 再省约 8 ms，且软解算力更低；ELD 的优势则在苹果生态的硬解通路与既有工具链集成。两条低延迟路线的取舍，本质又是 4.4 的生态层在起作用——技术差距是次要的，"谁的链路更顺"是主要的。

⚠️ 常见坑：ELD/LD 的码流与 LC 解码器不兼容——Profile 是能力契约，把 ELD 流喂给只认 LC 的硬件解码器，轻则报错重则输出噪声。跨平台分发音频时，若链路里任何一环是浏览器标准 Web Audio 或老旧硬件，用 ELD 前先确认解码端支持清单。

LD/ELD 的参数速查与选型口径

使用这张表的口径提醒：延迟列是算法延迟，端到端还要叠加 5.4 的整链账；码率列是语音内容的适用区间，音乐内容要上浮一档；v2 的增益集中在立体声场景，纯单声道通话不必启用。选型时的判断顺序依旧是 5.1 的三问——LD/ELD 只在"延迟硬 + 生态锁定 AAC"的窄条件下胜出（典型如苹果链路内嵌方案），一旦生态允许 Opus，同样的延迟预算下 Opus 的码率效率与容错配置都是更优解。

💡 关键直觉：LD/ELD 的存在本身就是一个证据——标准体系完全清楚延迟的重要性，只是架构基因让补课的成本居高不下。第 3 章你会看到，Opus 把"帧长可变"做成协议第一公民后，延迟从"补丁目标"变成了"默认属性"。

第二章收官。AAC 的证据链完整了：主场精致、低码率靠参数化、低延迟靠补丁。第 3 章换个视角，看一个从第一天就为交互而生的编码器如何重新回答同样的问题。