摘要

  • Lauri Ilola 与 Lukasz Kondrad 共同署名的 RFC 10034，规定了 V3C atlas NAL 单元的 RTP 承载方式，并用 SDP 的 V3C 分组说明哪些 atlas 与视频媒体行属于同一份表示。
  • 接收端可以拒绝个别媒体行，只接受子集。丢失一个分片、错误的解码顺序、不兼容的参数集或流间时间偏差，都可能让“同组”组件无法成为可用场景。
  • 该载荷格式不指定单一安全机制。每条组成流以及连接它们的 SDP、RTCP 都要分别证明来源、完整性和机密性；分组本身不会传递信任。

一块运维屏幕很容易提前宣布成功：四条媒体流都在发包，SDP 里又有一行 a=group:V3C 把它们列在一起。网络层看到的是共同名称与持续字节；渲染端需要回答的却是另一件事——这些字节有没有按同一套参数、顺序和时钟被重建成场景。

RFC 10034 的价值正在这条边界上。它于2026年8月作为 IETF 标准轨 RFC 发布，为视觉体积视频编码的 atlas 数据定义 RTP 载荷，为 V3C 参数定义 SDP 表达，也为组成同一表示的多条媒体行定义分组语义。标准没有把复杂性藏进“视频”二字，而是把依赖项暴露出来。

V3C 先把三维帧拆成多种二维表示。占用数据告诉解码器哪些像素参与重建；几何数据描述点在空间中的位置；属性数据可提供颜色、材质等性质；atlas 中的 patch 则记录二维区域怎样反投影回三维空间。它们共同服务一个结果，却不是同一种数据。

因此，atlas 不是场景的缩略图，视频组件也不是拿到就能摆回原位的普通画面。SDP 分组能说明“它们应当一起使用”，但只有接收、装配、解码与输出证据才能说明“它们确实一起工作”。

三种封包方式对应三种失效面

RFC 10034 为 atlas NAL 单元定义单 NAL 包、聚合包与分片单元三种结构。单包只装一份 NAL；聚合包至少装两个较小单元，用于降低开销；分片单元把一个过大的 NAL 拆到多个 RTP 包中。

它们的成功标准不能合并。聚合包必须落在一个 IP 包里，并应避免触发 IP 分片；聚合包本身不能再分片。分片单元不能嵌套。属于同一 NAL 的分片必须连续发送，RTP 序列号递增。若中间分片丢失，接收端应丢弃该 NAL 随后的分片。

于是，“99.9% 包已收到”仍可能掩盖一份不可恢复的 atlas 单元。总字节数看不出 AP 能否解析，最后一个序列号也看不出 FU 是否首尾完整。真正的回执需要记录 AP/FU 边界、起止位、缺失序列、丢弃动作，以及最终是否重组出可交给解码器的 NAL。

解码顺序还有另一套状态。当 sprop-max-don-diff 为零时，传输顺序必须等于解码顺序；大于零时，DON 与 DONL 允许两种顺序不同，接收端必须在解码前重新排列。RTP 序列号证明包经过网络的次序，DON 证明媒体逻辑需要的次序，二者不能互相代替。

时间也不是一块“流量正常”指示灯。atlas 使用 90 kHz RTP 时钟，接收端必须用 RTP 时间戳驱动显示。这个规定统一了一条流的时间基准，却没有证明占用、几何、属性与 atlas 都在可用窗口内抵达。流间同步要在实际消费这些组件的地方测量。

分组写的是意图，回答写的是选择

RFC 5888 提供通用 SDP 分组框架；RFC 10034 新增 V3C 语义。组行后面的 token 对应各媒体行的 mid。atlas 用 m=application 和 v3c 编码名，视频组件仍使用 m=video 与各自的 H.264、H.265、H.266 或其他 RTP 载荷格式。

这种拆分很重要。发送方无需把不同编码组件伪装成一条不透明流，接收方也能知道哪些媒体行属于同一 V3C bitstream。但这是一项声明，不是交付回执。

在单播 offer/answer 中，offerer 列出可用组件并说明哪些应共同消费；answerer 可以照单接受，也可以把不需要的媒体行端口置零。RFC 甚至明确允许在接收方完全或部分不了解 V3C 编码方案时只选择一个子集。

因此，一份语法正确的 answer 可以有意留下不完整表示。这未必是错误：某个应用可能允许无颜色几何，或因能力不足拒绝高成本组件。错误发生在观测系统仍把它写成“完整 V3C 场景”。

V3C 参数集同样需要独立判断。它描述解码与重建需要的总体资源，通常适合带外传输。若它在组件流已经开始后才动态抵达，而接收端不具备所需能力，RFC 提醒结果可能未定义。记录参数集字节，只证明声明存在；能力比对与解码结果才证明它可用。

同组不能让信任自动扩散

RFC 10034 没有为 RTP 强制一种安全方案。应用要按自身环境选择机密性、完整性和源认证机制。由于 V3C 会话可能由多条 RTP 流加 SDP、RTCP 组成，这项责任必须覆盖整张依赖图。

几何流来源可信，并不能补救未知来源的 atlas。RTP 载荷受保护，也不能补救被篡改的分组或参数信令。组成员关系只说明关联，不会替另一条流继承密钥与身份。

多播规则把问题说得更具体：参数集必须与原始来源绑定，只能用于解码同一来源的 bitstream。字段值碰巧一致，不是混用状态的授权。

RFC 7201 罗列保护 RTP 的方案与取舍，RFC 7202 解释为何载荷格式不应替所有应用选定一种方案。运维报告由此必须写清实际机制、覆盖的组件、信任锚、验证结果与盲区。“收到 RTP”或“识别 V3C 分组”都不是安全状态。

Kondrad 的贡献因边界清楚而有用

Nokia 官方人物页把 Kondrad 介绍为 Principal Standardization Specialist，参与 ISO/IEC 与 IETF 的沉浸式媒体标准。RFC 10034 正是两套标准体系之间的桥：ISO/IEC 23090-5 定义 V3C 编码模型，IETF 生态提供 RTP、SDP、分组和安全约定。

这仍是一项集体成果。Ilola 是共同作者，既有 RFC 提供协议基础，IANA 登记 application/v3c、v3cfmtp 和 V3C 分组语义。注册表说明公共坐标已经存在，不说明产品已经部署；Kondrad 的职位也不证明任何 Nokia 服务的配置或市场采用率。

一份范围受限的标准不等于一份价值受限的标准。RFC 10034 把封包、顺序、时间、参数、分组、协商、拥塞与安全边界逐一命名，使每项失败都能回到掌握相应控制权的团队。

Heng Lu 的运行代码优先原则给出最后的审计方法：保存精确 offer 与 answer、每个 mid、已接受与拒绝的媒体行、参数集哈希、组件映射、SSRC、安全关联、序列缺口、DON/DONL、AP/FU、流间同步、解码器版本与错误、重建帧数量和场景校验，然后重复测试。

第一份回执是“被声明为同组”，第二份是“包到达”，后面还有来源可信、组件完整、顺序正确、时钟对齐与成功解码。最后一份才属于重建场景。RFC 10034 让这条链可互操作，却没有把链条压成一枚绿色徽章。

来源