摘要

  • draft-ietf-mlcodec-opus-extension-06 借用 Opus 填充区承载可选扩展，让旧解码器忽略扩展后仍能播放基础层。
  • 长度越界、帧索引越界、扩展未知或本地拒绝时，扩展可被丢弃而基础音频不受影响；因此“解码成功”并不能证明扩展已应用。
  • 需要把基础解码、扩展解析、标识语义、SDP 协商、本地准入与最终输出保存为不同回执。

最安静的失败

一段音频没有中断，告警也没有响。发送端确实放入了扩展字节，接收端也识别出非零填充。但扩展声明的长度越过了包尾。按照草案，解码器必须忽略该实例；基础 Opus 数据仍可继续解码。听众听见了声音，运维只看见成功，会很自然地把“服务可用”写成“扩展有效”。

这正是证据边界最容易消失的地方。安全跳过是兼容性动作，不是功能完成动作。它证明解析器没有越界读取、基础层没有被可选数据拖垮，却没有证明扩展到达了目标帧、改变了解码状态，或者产生了任何增强输出。

为什么旧解码器仍能工作

RFC 6716 要求编码器把填充字节写成零，同时要求解码器接受任意填充值。草案利用这一不对称：全零仍是普通填充，非零则可被新版解码器解释为扩展。旧解码器不认识这套语义，只会丢弃填充，继续处理基础码流。

新版解码器在没有扩展时必须与旧版行为相同。编码器也不得为了扩展而明显降低旧解码器看到的非扩展部分质量。这个合同保护了兼容性底线，却没有承诺扩展上限。基础层声音良好，只能说明底线在这次观察中成立。

每个扩展实例以七位 ID 和一位 L 标志开始，之后可能有长度和数据。短扩展 ID 3 至 31 只能携带零或一个数据字节；长扩展 ID 32 至 127 可携带任意长度。长扩展的 L=0 通常表示占用余下全部填充，而且一个包里最多只能这样出现一次；L=1 则带显式长度。长度值 255 可以继续累加，但始终受包边界约束。

若长度本身都无法在包内读完，若所指数据越界，或 RTE 重复所需的载荷不足，违规实例必须被忽略。系统不应猜测，也不应把相邻内存当作数据。基础层继续输出，与扩展被拒绝可以同时为真。

帧归属不是附注

扩展属于具体 Opus 帧。结构 ID 1 是帧分隔符：一种形式前进一帧，另一种形式按随后的字节跨越更多帧。索引不得达到或超过包内帧数。越界索引关联的所有实例都必须忽略。

因此，解析出合法 ID 与合法长度仍不够。若实例被放到了不存在的帧，它没有可合法作用的对象。只记录“发现扩展 ID”会把空间上的存在误写成时间上的有效。

结构 ID 2 是 Repeat These Extensions。它可把当前帧中的一组扩展复制到后续帧，同时为每个重复实例提供新的载荷，从而减少重复 ID 和分隔符的开销。结果是：同一帧的完整扩展集合可能在包内并不连续。帧内次序仍有意义，具体扩展还可限制出现次数和相对位置。RTE 规定的重排等价不等于任意顺序都等价。

要证明扩展应用，必须保留 RTE 展开前后的序列、目标帧、长度消耗和拒绝原因。一个外层语法正确的包，完全可能只在基础层产生结果。

“支持”也允许不执行

草案要求解码器忽略不支持的扩展，并像它不存在一样继续。更关键的是，解码器即使技术上支持某扩展，也可以忽略它。代码存在不等于本地政策准入。构建选项可能关闭，资源预算可能不足，应用配置可能禁用，前置协商条件也可能没有满足。

这使单一“支持位”失去证明力。至少需要三个状态：实现中存在、当前会话允许、当前实例实际应用。再往后还要区分应用后的解码状态与用户观察到的结果。

对恶意载荷的要求也属于这一层。实现不得因扩展而越过已分配内存或消耗过量资源。解析器安全退回基础层，证明了防护可能奏效，却不能反推扩展内容正确，也不能反推每个资源限制都按预期执行。

SDP 声明仍只是声明

草案为 audio/opus 提出 extensions 与 sprop-extensions 两个列表，分别描述接收方和发送方支持的 ID。扩展自己的参数采用 extN-* 与 sprop-extN-*。识别扩展机制的接收端必须支持结构 ID 0、1、2，但无需在列表中写出它们。

SDP 参数必须明确指定，不得从另一份 offer 或 answer 盲目沿用。即便协商失败，接收端仍要能处理含未知或未协商扩展的包——这里的“处理”是安全跳过并保住基础解码，而不是执行扩展。

所以，会话没断并不能证明协商正确。可靠证据要把这次 offer、这次 answer、选中的参数、本地二进制与配置、实际收到的实例以及逐帧决策绑在同一时间线上。

注册号与运行语义

草案提出七位 Opus Extension IDs 注册表。0、1、2 为结构 ID；3 至 119 通过 Standards Action 分配；120 至 126 留给实验，并建议使用实验号与版本前缀、避免和其他实验冲突；127 为未来机制保留。

号码提供公共坐标，却不自动带来运行语义。两个实验可能碰撞；同一实验不同版本可能分歧；稳定分配也可能尚未进入某个构建。注册状态、实现状态、配置状态和实例结果必须分别记录。

相邻的 Opus HD 草案展示了扩展机制的一个使用者：它提出更高分辨率、20 kHz 以上内容和 96 kHz 处理，并提到代码与构建开关。但这些材料不证明任何具体端点启用了它，更不证明某次会话输出了增强质量。本文不评估 Opus HD，只借它说明通用容器和具体效果之间还有完整证据链。

草案状态与不确定性

修订版 06 是 mlcodec 工作组的活跃 Internet-Draft，日期为 2026 年 7 月 23 日，Datatracker 最后更新于 8 月 27 日，处于工作组最后征求意见阶段，预期为 Proposed Standard，2027 年 1 月 24 日到期。它不是 RFC，内容可能修改、替换或不再推进。

本报告没有测试编码器、解码器、浏览器、厂商、运营者或真实会话；没有确认攻击、崩溃、降级、ID 冲突或资源事故；也没有 CPU、内存、码率、频响或听感测量。场景用于界定证明要求，不是事故指控。

结论只能保持狭窄：基础音频播放证明了被观察到的基础输出。扩展是否生效，需要自己的回执。

来源