摘要

  • RFC 2029 要求每个 CellB RTP 负载以八字节头部开始：两个 16 位字段给出包内首个 4×4 cell 的 X/Y cell 坐标，另两个 16 位字段给出以像素计的图像宽高。
  • 多字节 CellB 代码必须完整放在一个包内。一个包丢失后，下一完整包仍从代码边界开始，并自带空间起点，不必依赖已经消失的前包末尾来寻找解释位置。
  • 这种设计限制了损害扩散，却没有重建丢失内容。坐标、尺寸、同帧时间戳和末包 Marker 都不能单独证明此前 cell 齐全、量化表一致、解码正确、画面连续或观众实际看到合格视频。

视频包丢失时，接收端可能同时失去两样东西：一段画面，以及理解后续字节所需的上下文。第一种损失无法靠一个坐标补回；第二种损失却可以通过更谨慎的分组格式缩小。

1996 年 10 月发布的 RFC 2029，正是为后一个问题设计。它把 CellB 视频装入 RTP 时，没有只依赖包序和帧时间，而是在每个负载里再放入一个空间锚点。于是，一个幸存的包不仅表明“我在这一帧”，还表明“我的第一个 cell 应从画面的这里开始”。

坐标说的是起点，不是完整性

CellB 负载头包含 Cell X Location、Cell Y Location、Width of Image 和 Height of Image。四项都是网络字节序的 16 位无符号整数。X/Y 使用 cell 坐标；每个 cell 覆盖 4×4 像素。宽高则仍以像素计算。

这一区别让接收端可以把压缩数据定位到画布上，而不必猜测 cell 坐标是否就是像素偏移。图像尺寸只允许在帧与帧之间变化，但 RFC 仍要求每包重复宽高。即使承载上一处尺寸信息的包没有到达，后续包也不会因此失去画布边界。

重复字段降低了依赖，却没有创造真实性。一个头部可以声明某个坐标，仍不能凭自身证明坐标有效、此前区域已收到、各包没有重叠，或数据最终覆盖整幅图像。它是一张地址标签，不是画面验收单。

不跨包的规则保护了解析边界

CellB 字节流并非所有指令都一样长。普通 cell code 长四字节，描述一个 4×4 cell；skip code 只有一个字节，可让解码器在当前帧中跳过一至 32 个 cell；另有两个单字节指令，分别宣布接下来 512 字节是新的 Y/Y 或 U/V 量化表。

RFC 2029 允许实现者选择从小包到整帧的任意包大小，却规定所有多字节码都必须完整留在一个包中。包边界不能把四字节 cell code 截成两半，也不能把一个量化表更新拆给相邻两个包。

因此，当中间一个包消失，下一包不会以某条失去开头的多字节指令残片起步。它从完整代码边界开始，自己的八字节头又指出首个 cell 的位置。语法边界和空间边界在同一处重新建立。

但没有任何一条规则传回丢失字节。RFC 2029 没有定义重传、纠删码、冗余 cell 或画面重建算法。所谓“恢复”，准确含义是后续完整包可以局部重新同步，而不是缺失区域被还原。

时间戳把包归进一帧，Marker 并不清点成员

RFC 2029 采用 90 kHz RTP 时间戳。同一帧的所有包使用相同时间戳，Marker 位标示帧末。时间戳给出帧归属，Marker 给出发送端声明的结束位置。

两者都没有列出这一帧理应包含哪些包。收到带 Marker 的末包，不等于中间无缺；看到一组相同时间戳，也不等于该组已经齐全。RTP 序列号能帮助接收端发现包号空洞和恢复发送顺序，但 RFC 1889 明确说 RTP 不保证交付、及时性、到达顺序或服务质量。

这正是证据阅读中最容易滑过的一步：边界标记能证明发送端如何标记一个包，不能自动证明标记之间发生的一切。

量化表说明“位置正确”仍可能“像素错误”

CellB cell code 的 U/V 与 Y/Y 字段不是逐像素颜色，而是色度和亮度矢量表的索引。后续字节的含义取决于接收端当时持有哪一版表。

RFC 描述了更换两张表的指令：每次更新包含 512 字节新表。随文样例编解码器没有实现这些功能，但规范为未来 codec 保留了它们。由于更新是多字节码，不跨包规则保证一份收到的更新不会被包边界切断。

如果承载整次表更新的包彻底丢失，情况就不同了。下一包仍可能坐标合法、代码完整、时间戳正确，甚至带着 Marker；接收端却可能继续使用旧表解释索引。它知道像素应放在哪里，却不知道是否用对了还原像素的表。

RFC 没有记录某次真实故障，这一结论来自格式内部两项规则的组合。它揭示了恢复能力的层次：包内自包含可以解除部分字节和位置依赖，无法自动解除所有历史状态依赖。

把运输、位置、语法和结果分开

审查一段 CellB/RTP 证据时，至少要分开四类记录。序列号说明包运输的连续性；X/Y 与宽高说明发送端声明的空间位置；代码边界说明幸存负载能否从完整指令开始；时间戳和 Marker 说明帧归属与声明的末包。

解码正确性在这四层之外。画面连续性和观看结果又在解码之外。要支持更强的主张，还需要保存实际负载、校验坐标覆盖、记录量化表版本、观察解码器输出、核对播放时间，并在讨论用户体验时取得终端侧测量。

IANA 至今仍在 RTP 固定负载类型表中登记 CelB：类型 25、视频、90,000 Hz、引用 RFC 2029。这是参数登记的可靠证据，不是现有部署的流量证明。RFC 2029 目前仍列为 Proposed Standard，也不等于市场采用、实现互通或播放质量已经得到证实。

RFC 2029 的历史价值，正在于它没有把丢包描述成可以被一个标志位消除的问题。八个字节让幸存包拥有自己的空间地址，不跨包规则让它拥有完整的语法起点。它让错误更可能停留在可定位的区域，同时也给后来的审计者留下了清楚界线：知道下一块放在哪里，绝不等于知道整幅图还完好。

来源