摘要

  • RFC 9559 可以约束 EBML 文档、轨道描述与 Block 结构；这份回执在编解码能力、参考帧闭合和同步呈现之前就已结束。
  • Cues 可以只覆盖部分时间与轨道，直播还可以合法地完全不用它；命中索引并不等于落在可独立解码、可见的目标帧上。
  • 默认与强制轨道标志只是播放器策略的输入，不能说明某位观众实际听到哪条音轨、看到哪条字幕或获得哪项无障碍服务。

一个 Matroska 读取器打开文件，接受 EBML 头部，再顺着合法的元素树向下走。最危险的简写由此出现：文件“能播”。RFC 9559 实际上说得更克制。它标准化的是容器——如何识别轨道、容纳编码帧、表达时间以及提供索引。每个机制都能留下证据，却没有任何一个等同于屏幕与扬声器上的结果。

这份 2024 年 10 月发布的 IETF 标准跟随了既有实现。RFC 8794 曾把单字节元素 ID 0x80 保留起来，而已经部署的 Matroska 实现却用它表示 ChapterDisplay。RFC 9559 将其合法化。这里最值得领导者注意的，不是谁“赢了”，而是文档层与运行代码层并非天然同步；新标准补上了共同契约，却不会自动证明历史文件与各家读取器表现一致。

可读取，只是一项有边界的兼容决定

EBML 头部分开记录 DocTypeVersion 与 DocTypeReadVersion。前者必须覆盖文件中使用的最高 Matroska 元素版本，后者声明读取器至少需要支持到哪个版本才能播放，而且允许功能有所缩减。规范自己的例子是：文件使用版本 4 的 CueRelativePosition，仍可把读取版本写成 2，因为该元素提高跳转精度，却不是常规播放的必要条件。

这是一种务实的互操作设计，不是“全部功能已验证”的证书。读取器遇到符合父元素长度约束的未知元素时应跳过。因此，“成功打开”可能恰恰意味着它有意识地忽略了另一款实现会采用的信息。要把结论向前推进，回执必须写明读取器版本、文档声明的版本以及跳过了哪些元素。

从 Block 到帧，还要补上参考历史

Block 与 SimpleBlock 把轨道号、相对 Cluster 的有符号时间戳、标志位、可选 lacing 数据和一个或多个编码帧放在一起。Xiph、EBML 与定长 lacing 能减少开销，也增加了内部边界的解析责任。找对元素终点，不代表已经找对其中每一帧的起止位置。

参考状态又形成一道关口。RFC 9559 明确警告：若把依赖其他帧的帧误当作随机访问点，跳转后可能产生错误输出，甚至崩溃。有些 AV1 或 VP9 intra-only 帧本身可以解码，却不会重置编解码状态；随后的画面仍依赖跳转前已丢失的历史。真正的问题不是“这里有没有一帧”，而是“从这里往后所需的所有参考是否闭合”。

容器中的 CodecID 和可选 CodecPrivate 负责标识编码格式并提供初始化材料。Matroska codec mapping 让开发者使用同一组标识，但它不会安装解码器、赋予资源，也不会验证输出。这个能力边界应由独立回执承担，不能借用元素解析器的绿灯。

读出时间戳，不等于构成观众时间线

Matroska 同时使用 Segment tick 与 Track tick。Block 的呈现时间要结合 Cluster 时间戳、有符号 Block 时间戳、TrackTimestampScale、TimestampScale，必要时还要减去 CodecDelay。负时间的帧可能必须解码，却不得向用户播放；浮点结果还应取最接近的纳秒值。

规范保留了一条很不舒服但很诚实的运行事实：许多历史读取器忽略非默认 TrackTimestampScale，所以不等于 1.0 的合法值在很多地方可能不起作用。同一份语法有效的文件，可能在两个读取器中形成不同的实际时间线。Track operation 也允许合成多条轨道；遇到帧重叠时，底层系统可能丢帧或以不同方式呈现，跨平台结果无法保证。

因此，运营证据必须保存计算输入，并对生成后的时间戳、音画同步和输出指纹进行比较。一个被正确解析的整数，只能证明读取器看见了它。

Cues 提供路线，却不完成跳转

Cues 为选定的 Cluster 位置建立索引，以便更快地访问绝对时间点。它可以覆盖每个 Block 的时间戳，也可以只选一部分。对于普通文件，规范建议写入 Cues，并建议为每个视频关键帧建立 CuePoint；当存在视频轨道时，音频索引可以省略。没有 Cues 时，读取器也能通过扫描文件尝试查找。

所以一次可辩护的跳转至少要回答四个问题：目标轨道与时间是否被覆盖；索引是否指向正确 Cluster 和相对位置；落点是否闭合参考状态；解码器向前重建后，实际显示帧是否落在允许的误差内。命中 Cue 只关闭其中的寻址步骤。

直播模式则主动改变证据面。连续 live Segment 不得使用 SeekHead、Cues、章节或附件；开头没有两类索引的流应被视为不可跳转。缺失在该模式下可以完全合规，但若产品承诺回看与拖动，它仍是决定性的能力缺口。

容器不能替观众做选择

FlagDefault 只是让某条语言轨道具备自动选择资格，播放器可以因无障碍偏好等原因覆盖它。FlagForced 要求在当前音轨通常不需要字幕时，仍优先显示某条字幕。听障、视障、描述音频、原声与评论轨道还有各自的标志。

这些都是策略输入，不是选择结果。它们无法说明用户偏好、播放器的冲突优先级，也无法证明最终送到输出设备的是哪些轨道 UID。真正的播放回执必须把容器标志、播放器设置、实际选轨与一个可听或可见的 canary 串在一起。

按照 Heng Lu 对运行代码与现实层的划分，RFC 是协调工具；结果属于具体执行链：精确字节、解析决定、帧边界、参考状态、时间计算、索引路线、选轨策略、解码器、渲染器与输出端。层次分开，标准的价值反而更大，因为每个结论都知道自己能说到哪里。