摘要

  • RFC 10034 定义 V3C 图集数据的 RTP 负载格式，并用 SDP 的 V3C 组关联图集、占用、几何与属性媒体行。该关系说明哪些分量属于一个表示，却不能证明必要分量均已抵达并完成重建。
  • 完成判定必须逐层核对会话协商、参数版本、授权来源、分片与排序、跨流时间关系、解码输出和应用探针。单条流的标记位、已接受的应答或密码学完整性都只回答其中一个问题。

一台远程巡检终端显示四个正常状态：图集流在收包，占用图连续，属性视频的丢包率没有越线，几何流也刚收到一个带标记位的 RTP 包。控制台于是宣布这一帧体积场景已经完成。

屏幕上的管道表面却少了一块。

原因不是整条几何流中断，而是一枚几何 NAL 单元被拆成三个分片后丢了中间一片。后续包继续到达，序列号继续增长，图集流也按自己的规则结束了访问单元。四个局部事实都可以为真，但缺失的字节没有因此恢复，三维表面也没有因此闭合。监控把“流仍活着”误写成了“场景已经存在”。

RFC 10034 于 2026 年 8 月进入 IETF 标准轨道。它解决的是一个精确的互操作问题：为 V3C 图集子比特流规定 RTP 承载方式，沿用相应视频编解码器的负载格式传送视频分量，并让 SDP 表达哪些媒体行共同构成一个 V3C 表示。这是一项重要的协调能力，也是一项边界十分清楚的能力。

三维场景在上网之前已经被拆解

V3C 并不是把一个可以独立显示的三维帧直接塞进一个包。它先把空间内容投影为若干二维表示，再附上把这些表示还原为空间关系所需的图集信息。占用分量说明哪些位置有效；几何分量描述重建点的位置；属性分量可以承载颜色、反射、法线或其他性质；图集则给出补丁及其逆映射。

ISO/IEC 23090-5:2026 的公开目录记录了 RFC 所依赖的 V3C 与 V-PCC 规范。RFC 10034 对整体架构的概述已经足以说明传输难题：接收端等的不是一张完整画面，而是一组只有在彼此对应时才有意义的材料。

这种分离在网络上继续存在。图集使用 application/v3c、90 kHz 时钟的 RTP 会话；占用、几何和属性则使用其视频编解码器对应的 RTP 负载格式。一次提议完全可能让不同分量采用 H.264、H.265 或 H.266，而图集仍是一条应用媒体行。

因此，“四条流在线”不是一个足够精确的运行结论。一条低优先级属性流在普通沉浸式浏览中可能可以舍弃，在材料缺陷识别中却可能决定结论。图集可以被完美分包，几何却可能不可用。网络对象都存在，并不等于业务对象已经重建。

V3C 组是一条关系，不是一张收据

RFC 10034 在 SDP 分组框架中增加了如下语义：

a=group:V3C 1 2 3 4

后面的标记对应各媒体行的 mid。RFC 5888 提供一般分组机制；新的 V3C 语义告诉应用，这些描述属于同一个 V3C 比特流。它不负责传送媒体，不验证发送者，也不读取解码器状态。

相同媒体行还可以参加 BUNDLE 协商。共用一条传输路径可以减少套接字和端口，却不会抹掉分量身份。接收端仍须把包归到正确的媒体描述、V3C 单元类型、参数集、图集和安全上下文。

a=v3cfmtp 既可出现在会话级，也可出现在媒体级。两者冲突时，RFC 10034 规定会话级取胜。这一优先级避免不同实现自行猜测，但它不会证明缓存的 offer、流内覆盖值和实际进入解码器的字节来自同一个会话修订。

IANA 的 application/v3c 登记 要求 sprop-v3c-parameter-set，并把该媒体类型限定在 RTP 分帧中使用。IANA 的 SDP 参数登记表 则提供共享命名空间。登记能够让标签互操作，却不能证明某个发送者确实提供了它、接收者确实支持了它，更不能证明现场会话已经产生画面。

参数集描述依赖，不证明接收能力

必要的 sprop-v3c-parameter-set 携带 Base64 编码的参数集字节，其中包含重建所需的资源与配置状态。RFC 10034 倾向在媒体开始前通过带外方式提供这些信息，因为等到收包后才发现能力不足，可能导致未定义行为。

其他参数继续限定分量类型、活动参数集 ID、图集 ID、属性分区、映射和辅助视频角色。规范也允许用四字节组合单元头携带同类信息，但禁止它与分离参数同时出现；两个并存的真相来源会制造无法解释的冲突。

带外的图集、公共图集和 SEI NAL 单元可以持续生效，直到同类型流内单元覆盖它们。覆盖意味着状态版本发生变化，而不是一次无害的元数据刷新。若接收端沿用旧的带外参数，同时接受新的流内媒体，即使每个包都通过了认证，也可能把分量装进错误的表示。

单播 offer/answer 同样没有“接受即完整”的保证。依据 RFC 3264，应答者可以接受支持的格式，并把不支持媒体行的端口设为零。RFC 10034 还明确容许只部分理解 V3C 的接收者选择一个子集。产品因此必须预先定义：哪些子集可渲染，哪些只可降级，哪些必须失败关闭。

标记位只结束本流的访问单元

RTP 提供序列号、时间戳、源标识与由负载格式解释的标记位。在 RFC 10034 中，标记位出现在当前 RTP 流所承载访问单元的最后一个包上。它有助于管理播放缓冲，却不是覆盖整个 V3C 组的提交事务。

图集负载有三种形式：单 NAL 包携带一个单元；聚合包携带至少两个小单元，并应保持在本地 MTU 以内；分片单元把一个 NAL 单元拆到连续 RTP 包中，禁止嵌套，也禁止在首尾分片之间插入同流其他包。

丢失规则尤其值得运维系统正面记录。只要一个分片丢失，除非已知解码器能处理不完整单元，接收者就应丢弃该 NAL 单元的后续分片。此后流量恢复只证明又有字节抵达，不证明刚才的单元被修复。

排序也会改变证据含义。sprop-max-don-diff 为零或缺省时，传输顺序就是解码顺序；非零时会启用解码顺序号，接收端要先重排再送入解码器。去包器还必须考虑当前流所依赖的其他流，并可能为跨流同步主动延迟处理。RFC 7798 展现了基于 NAL 的相近先例；熟悉的封包机制没有消除 V3C 的多分量依赖。

认证必须覆盖组合，但组合仍要验证

RFC 10034 没有为所有应用指定唯一安全机制。RFC 7202 解释了原因：RTP 负载格式不知道部署采用何种密钥、身份、单播、多播或信任模型。RFC 7201 梳理 RTP 安全选项，SRTP 则为适用会话提供机密性、认证和重放保护机制。

V3C 的具体责任仍然明确：RFC 要求考虑对所有组成子流做来源认证，并让 RTP、SDP 和 RTCP 对应发送者的真实意图。只保护图集、却从未绑定的来源接收几何，会把表示暴露给组合攻击。

然而，四条密码学有效的流也可能属于不同会话修订；通过重放保护的属性可能晚于当前图集；可信发送者也可能填错图集 ID。完整性证明受保护的字节没有被篡改，跨分量一致性和应用可用性还要另外举证。

拥塞动作会改变场景含义

RFC 10034 要求单播使用者监测丢包并实施 RTP 拥塞控制。发送方可以调低速率，接收方可以离开会话，任一方还可使用 RTP 熔断器。规范允许降低或移除较不重要的子流，但要求考虑整体体验。

“较不重要”不是 RTP 字段，而是产品决定。去掉颜色对几何远程呈现或许是合理降级，对材料检测却可能让分析失真。辅助分量的退出可以降低保真度，也可以直接改变结论。拥塞动作必须触发语义状态变化，例如“仅几何降级模式”，而不能在带宽下降后沿用“完整成功”。

用完成账本替代一墙绿灯

每次会话修订都应保存 offer 与 answer 的指纹、V3C 和 BUNDLE 组的 mid 成员、参数集与单元头指纹、编解码器、分量角色、图集 ID、授权来源、SSRC 和传输五元组。每条流再记录首尾包时间、丢包、抖动、重排深度、分片闭合情况、解码顺序状态和访问单元边界。

账本不能止于 RTP。还要记录哪些 NAL 单元真正进入解码器、解码错误、重建帧标识、应用渲染或分析探针、降级决定、熔断动作和最终终态。“已接受”“正在接收”“已去包”“已解码”“可用于业务”必须是不同状态。

这与 Heng Lu 的运行代码优先相呼应：证据应来自实际执行路径，而不是标准名称或声明的组。他提出的最小初始规范与本地化决策也适合这里：共同语法保持克制，能力与采用决定留在参与者本地。形式控制与实际控制的区分进一步提醒我们，创建会话的一方可以命名组成部分，却不能由此控制所有网络副本、接收缓冲区与最终输出。

RFC 10034 的价值不是替运营者宣布成功，而是让运营者更准确地知道必须核对什么。