摘要

  • draft-ietf-avtcore-rtp-jpegxs-3ed-08 为既有模式保留 RFC 9134 的 RTP 分包、头部格式和总体载荷结构，同时加入第三版 JPEG XS 的时间差分编码（TDC）。
  • 非 TDC 码流可以独立解码为一幅图像；TDC 码流则可能需要从前一码流重建并保存在正确缓冲区中的量化小波系数。
  • SDP 精确回显、当前载荷合法和 fbblevel 参数一致，只能证明能力与声明；它们不能证明上一帧状态未丢失、内存带宽持续达标或观众最终看到了正确画面。

一张先于画面抵达的回执

设想接收端完整接受 JPEG XS 的参数组合，在应答中逐项原样回显，随后收到格式正确、SLI 标记位置也正确的 RTP 流。控制面上的每项记录都是绿色。此时仍有一个问题没有答案：当前图像需要的上一组系数，是否还在正确的缓冲区里？

这正是 TDC 改变证据结构的地方。没有 TDC 时，一个码流对应一幅可独立解码的图像。启用 TDC 后，当前码流可以引用由前一码流重建的量化小波系数。逐行视频使用一个帧缓冲；隔行或 PsF 视频使用两个分别对应不同场的缓冲。系统即便“有历史数据”，也必须证明它来自正确的前序图像和正确的场。

第 08 版日期为 2026 年 9 月 22 日。Datatracker 将其列在 RFC Editor Queue，目标状态为 Proposed Standard；草案说明它将取代 RFC 9134。它目前仍是 Internet-Draft。流程位置不是 RFC 正式发布、实际实现、生产部署或互操作结果的证据。

兼容的是传输外壳，不是过去状态

新草案有意保留 RFC 9134 的 RTP 分包方式、头部和总体载荷结构，使未使用新时间特性的既有模式不必承担全面破坏式变更。这是一项清晰且有价值的兼容承诺。

它没有让时间依赖也自动兼容。TDC 以 SLI 标记界定 slice；在按 slice 分包时，SLI 与原有 SLH 扮演相同的分包边界角色。这个等价关系只说明数据在哪里可以成为一个传输单元，并不说明该单元能够脱离前一图像独立恢复。

因此，一份整齐的抓包记录可能仍然少了最重要的一层。RTP 序号说明包的到达和次序；解码器状态谱系说明究竟哪份历史系数参与了重建。分包边界不天然等于恢复边界，更不等于结果证明。

fbblevel 是下限声明，不是实时仪表

新增的可选参数 fbblevel 只允许用于 TDC，并且必须与 JPEG XS picture segment 内信令的 FBB level 一致。它表达的是帧缓冲读写带宽的最低要求。

它不在运行时测量内存。终端可以真实声明自己支持某个等级，但在特定负载下是否持续提供该能力，仍要由本地观测回答。草案并未声称存在此类故障；它只是没有把性能测量的职责交给这个参数。

除 rate 的特殊处理外，媒体参数属于声明信息，并与载荷中的数据重复。当 SDP 与载荷冲突时，以载荷为准。运营者因此需要保留两份证据：协商记录说明双方同意尝试什么，载荷说明发送端对具体编码图像实际声明了什么。

精确回显只是一份能力合同

单播 offer/answer 的规则很严格：应答方必须支持要约中的全部参数值，否则就应拒绝；一旦接受，就要原样回显。这消除了悄悄接受一部分参数的模糊空间。

但精确回显不检查参考缓冲，也不知道依赖图像之前是否发生丢包，不测量持续内存带宽，更不观察应用层显示的画面。它回答“我声明能够处理这组能力”，而不是“这一帧已经正确交付”。

网络要求也保持了同样的边界。best effort 使用必须监测丢包并执行拥塞控制；若使用增强服务，接收端还应核实所请求的服务是否真的得到交付。请求、预留和实际获得不是同一个事实。

不让一盏绿灯代表五层现实

Lu Heng 的“最小初始规范”给出了合适的标准边界：共享层只固定互操作所需的参数含义、分包方式、优先级和依赖表达，不接管本地内存配置、恢复策略与结果观测。

“运行代码优先”则让部署中的解码器成为比能力表更强的证人。“现实层分离”要求把协商能力、载荷声明、RTP 接收历史、缓冲状态连续性和实际输出拆开记录。若压缩成一个“会话已接受”，符号性回执就会替代它从未进行过的物理测量。

来源与边界

这些来源说明了格式、协商规则与运行注意事项。它们没有证明任何具名实现、生产部署、互操作测试、实测丢包响应、解码器缺陷、事故、画质结果或采用率。本文分离证据层，不是在指控某个真实系统已经失败。