摘要

  • RFC 3984 把 H.264 图像数据与解释这些数据所需的序列参数集和图像参数集视为两类独立状态；slice 能引用规则，却不等于已经交付规则。
  • 真正的风险是配置竞态：参数集可能尚未到达、更新晚于依赖它的媒体、旧包尚未排空时标识符已被覆盖，或多个写入方对同一标识符赋予不同含义。

假设一次分辨率切换发生在 10:00:00。RTP 监控显示新图像包从这一刻起连续抵达，没有丢包尖峰，时间戳也正常前进。但解码器直到稍后才装入新的图像参数集。两只钟都在走，只是它们没有在同一时刻越过边界。对传输来说包是准时的，对解码状态来说包却来早了。

RFC 3984 于 2005 年 2 月规定 H.264 视频的 RTP 负载格式。它的状态页、勘误记录和 Datatracker 历史表明，该文档后来被 RFC 6184 取代。它的历史意义不只是如何拆分或聚合 NAL 单元，还在于它明确处理了一种更隐蔽的状态：图像包之外，解码器还必须先拥有解释图像的规则。

H.264 把会被多个 slice 重复使用的信息提取到参数集中。序列参数集 SPS 描述编码视频序列的共同属性；图像参数集 PPS 描述编码图像使用的属性，其中可以包括图像尺寸、编码模式以及宏块到 slice 组的映射。slice 头部不重复全部内容，而是携带标识符，指向应当使用的参数集。

这种间接引用减少了重复，却产生了先决条件。标识符只是名称，不是内容。依赖它的 NAL 单元进入解码顺序之前，接收端必须已经得到正确版本，并把它放在正确槽位。包校验无误并不能证明该槽位已经就绪；标识符相同也不能证明其中的含义仍然相同。

这正是 RFC 3550 所划定的层次边界。RTP 序列号可以帮助发现丢失、恢复包序；时间戳表示采样时刻，用于同步和抖动计算。其状态页、勘误和 Datatracker 记录都没有让这些字段承担 SPS/PPS 版本登记功能。第一只钟告诉你媒体如何移动，第二只钟仍需另行取证。

RFC 3984 给参数集交付归纳了三种原则。原则 A 是在 RTP 会话开始前，通过可靠带外通道交付；原则 B 是会话进行时，通过可靠带外通道更新；原则 C 是让参数集随 RTP 媒体在带内传输。2005 年原文对 A、B 推荐可靠带外方式；带内方式则需要重复、重传或前向纠错等保护，因为一次参数集丢失可能影响后续许多 NAL 单元。

初始状态可以写入 sprop-parameter-sets。该媒体类型参数携带以 base64 表示的参数集 NAL 单元。RFC 3984 要求它们在解码顺序上先于任何引用它们的单元。规范还特别说明，这不是接收端能力声明。它描述发送方准备使用的状态，不能被拿来证明接收端支持所有列出的配置。

带外状态通常与会话描述相连。RFC 4566 及其状态、勘误、Datatracker 记录把 SDP 定义为描述格式，而不是解码器内部安装完成的通用回执。RFC 3264 规定 offer/answer；它的状态、勘误和历史显示，一次只能有一个尚未完成的 offer，这让协商可以串行化。

串行化能帮助切换，却不能抹平所有事件。RFC 3984 建议：若在会话中可靠地带外更新参数集，发送方应等信令确认后再发送依赖新状态的 NAL 单元。工程系统仍要继续追问，确认究竟代表消息已到达、内容已验证、状态已写入，还是状态已经激活。它更不等于最终画面已经渲染成功。

标识符复用暴露了第二只钟的危险。旧 PPS 的标识符如果被立即赋给新定义，而旧 slice 仍在网络、重排序队列、抖动缓冲或解码器内部等待，那么旧 slice 会用同一个名称解析出新的含义。所有字节都可能正确，语义却已经错位。

规范因此建议选用长时间未使用的标识符，或者增加新的标识符，不要过早覆盖仍可能被引用的定义。“长时间”不能只按一次往返时延计算，它还必须覆盖路径重排、缓存深度和解码器保留期。配置版本的有效期由整条依赖链决定，而不是由写入动作单方面决定。

多方会话又把时间问题变成命名权问题。两个编码器可能各自合理地选择同一个标识符，却给出不同参数集。进入混合器或网关后，一个共享命名空间不能同时容纳两种含义。控制器必须划分标识符范围、重写引用，或隔离解码上下文。没有统一所有者时，局部正确会合成为全局冲突。

带内与带外同时写入也会制造陈旧状态。RFC 3984 要求原则 B 与原则 C 不应在缺少充分同步的同一会话中混用。晚加入者可能从 SDP 得到初始参数集，却错过此前发生的带内更新；丢失更新的接收端也可能一直保留旧定义。把不同通道分配到不同标识符范围，可以降低同名异义的风险，但仍不能替代版本和确认管理。

后来的 RFC 6184 取代 RFC 3984。它的状态、勘误和 Datatracker 历史显示，新规范不再一般性偏好带外交付，而是允许带内和带外两种方式，并加入 in-band-parameter-sets 等协商规则。因此，历史结论不能被写成“带外永远更好”。真正持续的要求是：所选方式必须明确，更新与依赖媒体必须协调。

RFC 7798 后来处理 HEVC 的 RTP 负载格式，其状态、勘误和 Datatracker 记录提供了可比证据：视频负载格式反复遇到“媒体与解释状态分离”的问题。这不能证明所有实现具有同一行为，也不能证明 RFC 3984 的普及程度。

参数集的影响半径还解释了安全要求。普通图像包损坏可能影响有限区域，伪造或篡改参数集却可能改变许多后续 NAL 单元的解释。RFC 3984 因而讨论完整性保护和来源认证。控制状态的字节数很少，权力却很大。

故障调查必须同时校准两只钟。除了 RTP 抓包，还要保存 SDP 交换、信令确认、所有带内参数集、标识符的写入者、负载类型切换以及接收端缓存窗口。要证明某张图像为什么失败，关键问题不是“包在不在”，而是“它被解码时，所引用标识符里究竟是哪一版规则”。

RFC 3984 留下的是一条通用的分布式系统经验：数据与解释数据的状态可以走不同路径、采用不同可靠性、在不同时间生效。把两只钟画在同一监控面板上，并不会让它们自动同步。只有明确版本、所有权、确认边界和旧状态排空条件，图像包的到达才会真正转化为可解释的媒体。

来源