摘要

  • RFC 2032 禁止一个 H.261 宏块跨越两个 RTP 包，并要求包在宏块边界开始和结束；包头复制从该位置继续解码所需的预测状态。
  • 这个设计把丢包后的语法损伤限制在局部，却不会重建缺失宏块，也不能保证帧间预测所依赖的参考画面仍然正确。
  • 可选的 H.261 专用 FIR 与 NACK 报文能请求完整帧内刷新或指出丢失序列号；“提出请求”仍不是“请求送达、执行并在播放期限前修复”的证明。

一个包完全可读，并不表示它所属的画面完整。RFC 2032 最有价值的地方，正是没有把这两个事实混为一谈。

1996 年 10 月发布的这份 Proposed Standard 规定了 H.261 视频如何直接装入 RTP。H.261 原本为固定速率 ISDN 设计，H.221 帧还可以携带音频、数据和错误校正。RFC 2032 没有把这些 512 位帧整体搬到互联网，而是直接发送 Huffman 编码的视频比特流。网络丢包因此成为必须面对的现实：格式不能保证每个包抵达，只能安排好丢失发生后从哪里继续。

宏块边界是一项故障隔离决定

H.261 的图像向下分为 GOB 与宏块。每个 GOB 包含 33 个宏块，一个宏块对应 16×16 像素区域。RFC 2032 把宏块选为分片单位：包必须在宏块边界开始和结束，一个宏块不得跨包，也不能在 GOB 头与第一个宏块之间切开。

这不是排版偏好，而是为了保留可解释性。Huffman 码是变长的；如果在没有上下文的任意位点重启，接收端可能无法判断后续比特究竟是字段起点还是上一段代码的残余。已知的宏块边界把下一个收到的包变成一个可以追责的解析入口。

然而，语法独立不等于视觉独立。H.261 使用帧间和差分编码。后续宏块即使能被正确解析，也可能引用一幅已经受损的参考图像。RFC 2032 明确承认，错误区域可能持续存在，直到对应宏块重新用 INTRA 模式编码。新的边界阻止解释错误无限扩散，却不会把已经丢失的像素变回来。

四字节包头保存了起点记忆

H.261 RTP 载荷头只有 32 位，却承担了重新进入比特流的关键责任。SBIT 与 EBIT 指明首尾字节中有多少位不属于视频数据，让位级的 H.261 语法能够装入字节对齐的网络包。

GOBN 指明包从哪个 GOB 起步，值为零时表示从图像头开始。MBAP 保存相对 GOB 起点的宏块地址预测量，QUANT 保存下一个宏块使用的量化预测值，HMVD 与 VMVD 则保存参考水平和垂直运动矢量数据。它们不是画面内容，而是解释画面内容所需的起点状态。

其中 MBAP 很容易被过度解读。它不是像素矩形的地理坐标，更不是某块画面已经恢复的证明；它只是地址差分解码必须知道的预测量。HMVD/VMVD 同样只恢复运动矢量差分上下文，不能证明所指向的参考图像正确。

I 与 V 两个位也只是保守提示。I 表示码流是否只包含 INTRA 宏块，V 表示是否可能使用运动矢量。规范说它们可从比特流推断，并允许符合实现始终使用较保守的 V=1、I=0。它们帮助解码器选择安全路径，却不是逐宏块审计，更不是质量评分。

知道帧在哪里结束，不等于知道帧是否完整

同一幅视频图像的 RTP 包使用相同的 90 kHz 时间戳。marker 位在一帧最后一个包上置 1，使接收端不必等到下一幅图像的开始码就能判断当前帧结束。若一个包包含多幅图像，RTP 时间戳只属于第一幅，后续显示时刻还要根据 H.261 图像头推导。

这些字段能定位时间和终点，却不能补齐序列。marker=1 只证明发送端把这个包标成帧尾；它没有证明此前所有序列号都已抵达。RTP 序列号能让接收端看见缺口，而 UDP 发送动作本身不会告诉发送端数据报是否成功到达。“收到最后一个包”与“收到完整一帧”是两条不同的证据。

限制错误，不等于纠正错误

RFC 2032 提出三类缓解办法：编码器可以周期性发送全 INTRA 帧，可以根据丢包调整刷新频率，也可以在接收端发现损伤后接受刷新请求。每一种都建立了一条可能的控制路径，没有一种让控制路径自动闭环。

宏块边界与复制状态解决的是窄故障：少一个包之后，后续包仍可能被解释。如果没有它们，解码器甚至可能失去后续代码的语法位置。有了它们，丢失区域仍可能没有数据，错误参考仍可能污染预测，迟到的修复仍可能错过播放窗口。故障隔离保护未来的可解释性；错误修复还需要额外动作和回读证据。

FIR 与 NACK 把意图写进序列空间

RFC 2032 还定义了可选的 H.261 专用 RTCP 控制报文。Full INTRA-frame Request 使用 Payload Type 192，请求编码器把下一帧全部用 INTRA 模式编码，SSRC 标识发出请求的接收端。Negative Acknowledgement 使用 Payload Type 193：FSN 是接收端认为最先丢失的 RTP 序列号，16 位 BLP 则用位图表示其后十六个序列号中的缺失。

FIR 的语义是“请重建预测起点”，NACK 的语义是“这些序列位置没有看到”。二者都把接收端判断转成可传递的坐标。

但它们都是可选机制。规范警告，大量参与者同时发送负面确认会造成负面效果；其直接从解码器发往编码器的做法，只适用于没有 mixer 或 translator 的拓扑。IVS 示例也只在接收者很少时启用反馈。支持能力、反向路径、会议规模和中间设备因此都是前提，而不是报文字段能够证明的结果。

捕获到 FIR，只能证明某个接收端生成了刷新请求；它不证明反向路径送达，更不证明编码器执行。捕获到 NACK，只能证明接收端认为哪些包缺失；它不证明源端支持重传、数据赶在播放前回来或修复图像进入显示设备。反馈坐标是强诊断证据，除非观察完整闭环，否则是弱结果证据。

最小共同层没有替现实做决定

按照 Lu Heng 的“最小初始规范”视角，RFC 2032 恰当地规定了独立实现必须共享的事实：合法切分点、接续上下文、时间戳、帧尾和可选反馈语法。缓存多久、何时刷新、是否重传、愿意承担多少时延，仍是实现与运营者的本地决定。

“running code primacy”进一步要求把文档、实现、网络和结果分开。字段版式已发布，是一条事实；编码器正确填字段，是另一条；双向网络送达，是第三条；解码器按时显示正确画面，是第四条。用前一层的词汇冒充后一层，才是最危险的误判。

RFC Editor 如今把 RFC 2032 标为已被 RFC 4587 取代。本文不借此扩展后继规范；历史价值已经足够清楚：它没有承诺无缝视频，而是把一次丢失可能造成的不可解释范围缩小，并给修复意图一个地址。画面是否真的回来，仍要另行证明。

来源