摘要

  • RFC 9584 用单 NAL 包、聚合包和分片单元承载 EVC。它能为解码器准备有序输入，却不宣称解码器一定产出画面。
  • 序号、M 位、时间戳、DON、PLI 与 FIR 都只回答一个有限问题。要声称播放成功，必须另外取得解码、呈现与显示面的回执。

一次直播故障中，网络侧可能拿出近乎完美的曲线：序号连续、带宽充足、访问单元末尾的 M 位存在、90 kHz 时间戳稳定递增。客户端却仍是一块黑屏。两份记录并不冲突。网络记录证明观察点收到了格式正确的 RTP 流；它没有证明参数集齐全、参考帧可用、解码器接受码流，也没有证明生成的帧赶上显示时刻。

RFC 9584 在 2024 年 6 月成为 IETF 标准轨 RFC。它解决的范围很具体：如何把 Essential Video Coding 的 NAL 单元装入 RTP。小的 NAL 可以独占一个包；同一访问单元中的多个 NAL 可以进入聚合包；太大的 NAL 可以拆成多个分片单元。该设计沿用了 H.264、HEVC 和 VVC 载荷格式的成熟思路。沿用说明接口并非凭空发明，不等于任何实现都已经互通。

RTP 头部中的每个字段都应受到语义约束。序号帮助接收方恢复发送顺序，并不保证每个包都送达。监测镜像本身也可能丢包，或者看见一个随后被终端丢弃的包。M 位表示当前 RTP 流中一个访问单元的最后一个包，不为此前所有包的到达背书。时间戳给出采样和显示时序参考，不是准时显示的收据。SSRC 标识来源，在缺少合适安全机制时，也不是可信身份。

分片最能暴露“边界标记不是完整性”的问题。FU 的起始位和结束位标出一个被拆分 NAL 的两端。接收方把连续分片的载荷拼接起来才能重建 NAL。若中间分片丢失，规范通常要求丢弃同一 NAL 后续分片，除非已知解码器能安全处理不完整输入。看见结束位，只说明末片出现；不能让缺失的中段重新存在。

聚合包则把另一种风险集中在一个包内。它至少包含两个、且属于同一访问单元的 NAL，并按解码顺序排列；聚合包不能嵌套，也不能把 FU 装进去。整个 RTP 包校验正确，仍可能含有错误 NAL、缺失的依赖状态，或接收方不支持的工具。包完整是送入解码器的前提，不是解码器的判决。

DONL 与 DOND 用来推导绝对解码顺序 AbsDon。这个值告诉去分包缓冲区应先向解码器交付哪个 NAL。它允许合理的空洞，因为网关可能不转发较高时间层或部分 SEI；相同值也可能容许任一顺序。解码输入顺序与画面输出顺序、显示截止时间和用户可见结果并不是同一事实。

规范还明确区分去分包缓冲与抖动缓冲。前者重建并重排 NAL，后者吸收网络时延变化。设备即使拥有足够的去分包容量，也可能因为抖动预算、解码负载或渲染队列不足而错过呈现。把两个缓冲区合成一个“正常”指示灯，会把两类故障压扁成无法追责的绿色状态。

PLI 和 FIR 也只是恢复链上的动作。PLI 表示一个或多个画面丢失了数量未定义的编码数据；FIR 要求发送端产生 IDR 画面，并在没有带外确认时带上参数集。发出请求不等于发送端执行，IDR 到达不等于解码成功，解码成功也不等于观众已经看到恢复后的画面。

RFC 9584 对边界说得非常直接：载荷格式本身不是完整系统。RTP 不预留资源，也不保证服务质量。保密性、完整性和来源真实性需要应用选择相应的 RTP 安全机制。IANA 登记 video/EVC 与 90 kHz 时钟，只证明代码点协调完成；它不能证明某个产品实现了、协商了或正确运行了该格式。

因此，可信链条必须保留每一个连接：目标终端收到包；来源与完整性验证通过；分片集合齐全；NAL 重建完成；解码顺序确定；参数集、profile 和工具能力匹配；解码器产出画面；画面赶上截止时间；渲染器提交；显示面更新。上游回执可以授权下一步处理，却不能替下游结果签字。

来源