摘要

  • RFC 3533 用 OggS 捕获模式、流序列号、页面序号、分段表和 CRC，把 Ogg 页面做成了可以重新定位并独立检查的单元。
  • 一个编解码数据包却可以横跨多个页面；后页通过 CRC，不代表前页中的起始片段仍在，更不代表媒体真实、完整、同步或已经播放。

最容易误判的场景，不是一个明显损坏的页面，而是一个毫无损伤的后续页面。它的头部能解析，CRC 完全匹配，第一个数据包却从已经丢失的前页开始。校验结果没有错；错的是把“本页有效”升级成“媒体有效”。

RFC 3533 于 2003 年 5 月发布，属于 Independent stream 的 Informational 文档。它定义 Ogg 封装格式第 0 版，不定义音频或视频编解码器。编码器产生逻辑比特流，并把它组织成数据包；Ogg 再把数据包切成 segment，把若干连续 segment 装入 page，并把一个或多个逻辑流的页面交错成物理 Ogg 比特流。容器负责边界与搬运，内容含义仍由 media mapping 和 codec 决定。

四字节捕获模式 OggS 是页面起点的地标。解析器在损坏区域之后可以重新扫描它，但找到这四个字节只产生候选边界。随后还要读取头部、解释 segment table、计算页面实际长度，再核对 CRC。32 位 CRC 使用多项式 0x04c11db7。已验证勘误 8825 澄清：计算覆盖 CRC 字段清零后的页面头部，也覆盖页面内容。它因此不是只检查头部，却仍只是页面级意外损坏凭证，不是数字签名。

segment table 把边界问题暴露出来。每个 lacing value 描述一个 segment；255 表示同一数据包还要继续，小于 255 才结束数据包。0 既可以表示零长度数据包，也可以结束长度恰为 255 倍数的数据包。页面头部还有 continued-packet 标志，说明本页第一个数据包始于前页。于是，一个数据包横跨多页完全符合格式。当前页面的 CRC 可以为真，它所依赖的前半段却已经不存在。

page sequence number 提供另一类收据。它在每个逻辑比特流内分别递增，所以即使音频、视频和元数据页面彼此交错，接收方仍能发现某一路少了页面。发现缺口不等于恢复缺口。序号只能证明观察到一次跳跃，不能重建丢失字节，也不能告诉人们哪些采样或画面受到影响。即便序号连续，也不能证明应用保存、重组、解码并呈现了每个数据包。

bitstream serial number 的边界同样明确。它是在一个物理流内区分逻辑流的随机标签，方便 demultiplexer 把页面送回正确的解码实体。RFC 3533 明说，这个号码与内容或编码器没有关联。它不是作品 ID、作者身份、设备证书、账户、版权声明或来源证明。若业务系统把它解释为这些含义，新增的是业务假设，不是协议事实。

BOS 与 EOS 标志给出逻辑流的开头和结尾。BOS 页携带由 media mapping 规定的 codec 识别信息，数据开始前还可以有更多头部数据包。EOS 页甚至可以不含媒体内容，只保留位置和结束标志。grouping 让多个逻辑流同时开始并交错页面；chaining 把完整物理流首尾相接。这些结构符号说明容器如何排列，却不保证边界之间的预期内容一个不少。

granule position 更不能被直接叫作时间。RFC 3533 明确说，Ogg 没有“时间”概念；它只知道顺序递增、没有单位的位置标记。音频 mapping 可以把它定义为样本数，视频 mapping 可以用画面数，若本页没有数据包结束，还可使用负一这一特殊值。只有理解特定 codec API 和 mapping 的上层应用，才能把这个字段换算成时间。

后来 Opus 的 Ogg mapping 正好说明了这种分权。RFC 7845，以及取代它的 RFC 9639，规定 Opus 使用 48 kHz granule 时钟，并定义 pre-skip、尾部裁剪与 seek 行为；RFC 6716 则定义 codec 本身。那些规则不是八字节 granule 字段自动携带的常识，而是具体 mapping 赋予字段的意义。离开 mapping，把数值当作秒数，就是从符号臆造现实。

MIME 名称也只承担有限职责。RFC 3534 最初注册 application/ogg；RFC 5334 后来废止它的原定义，重新界定用途，并加入 audio/ogg 与 video/ogg。IANA 当前登记这些名称。正确的 media type 能帮助软件选择处理器，却不能证明这个对象的页面连续、codec 可用、轨道同步、内容安全或已经成功播放。

安全边界并未藏在校验和后面。RFC 3533 不为容器或其中的逻辑流提供通用加密与签名；如果内容格式另有机制，Ogg 可以承载加密或签名内容，但页面 CRC 不会因此变成真实性证据。文档还要求实现正确处理被操纵的比特流、缓冲区溢出等风险。语法可解析，只能说明解析阶段暂时前进了一步，不能替后续内存访问与 codec 状态背书。

当前勘误记录也要求区分证据状态。勘误 6796 已 Verified，把示例中的“pages”改为“segments”；勘误 8825 同样已 Verified，澄清 CRC 覆盖头部与内容。技术勘误 8824 认为原文没有充分规定 CRC32 的反射等参数，但目前仍是 Reported。可以把它写成公开问题，不能把它悄悄当成已经生效的规范修改。

因此，一条可审计的媒体接收链至少包括：收到字节、找到捕获模式、确认页面边界、解析分段表、验证 CRC、检查每个逻辑流的页面连续性、重组完整数据包、选择正确 mapping、接受 codec 头部、转换 granule、同步多路流、解码采样或画面、渲染输出、观察听众或观众实际收到什么。RFC 3533 的历史价值，不只是给前几个环节加字段，而是没有假装它们已经等于最后结果。

来源