摘要

  • RFC 2343 用 picture 边界、90 kHz 时间戳、Audio Length 与带符号的 Audio Offset 描述同包 MPEG-2 音视频关系。
  • 这些字段是发送端的封装声明；包是否到达、状态是否重组、解码是否正确、音画是否同步、设备是否输出以及观众是否看到，仍是六组以上的独立事实。

一只包为何容易被看成完整节目

Bundled MPEG 的直觉很强：同一只 RTP 包先放若干完整视频 slice，再放若干完整音频 frame。固定 RTP 头给出序号、picture 时间与 picture 结束标记；BMPEG 专用头再写明 picture 类型、头部状态是否改变、音频占多少字节，以及音频起点相对 picture 时间戳偏移了多少样本。

对 1998 年的视频点播系统，这种设计很实用。一套节目只占一个端口，服务器磁盘里原本交织存放的音画不必拆成两条流，头部开销可能下降，接收缓存也可能比两条独立延迟路径更小。RFC 2343 的例子估算，在约 4 Mbps 的 MPEG-2 材料上，整体头部开销可降低约 1%，约等于 40 Kbps。

规范把这种同包关系称为“隐式同步”。这个词描述的是时间信息被放在一起，并不是电视机或播放器签发的同步回执。包中同时出现两种媒体，最多证明发送端给了它们共同的运输坐标。

捆绑本身就是一笔取舍

RFC 2343 是 Experimental 文档，明确不构成 Internet standard。它没有把捆绑写成通用最优解，而是说：当单端口、低开销和交织存储的收益足够重要时，可以牺牲分离音频流与视频流的模块化。

收益与风险因此来自同一个结构。一只包丢失，画面和声音都可能受损；只想接收一种媒体的终端失去部分独立性；两种媒体被更早地绑定，也让发送端的包尺寸、路径 MTU、接收缓存与解码状态互相牵连。

RFC 2343 还省掉了它认为与 RTP 重复的 MPEG systems-layer 信息。省字段并不等于省责任。职责只是被转交给 RTP、应用和接收端。所有实现若没有对这次职责切分保持一致，语法仍然可以正确，行为却会分叉。

应用边界必须落在包边界上

规范规定：Video_Sequence_Header 出现时必须从 RTP payload 开头开始；GOP_header 要么从开头开始，要么紧随 sequence header；Picture_Header 要么从开头开始，要么紧随 GOP_header。每只包还必须包含整数个 video slice。

这些规则让接收端更容易找到恢复起点，却不能阻止下层分片。发送应用要调整 slice 尺寸和每包 slice 数，尽量避免超过 path MTU。如果包仍然过大，只能依赖下层分片，而规范提醒这可能干扰 RSVP 等集成服务的包分类。

音频也有精确规则。视频之后要放足够多的完整 audio frame，覆盖本包视频片段的时长。如果一个音频帧比本包视频时段长，后续几只包可以没有音频；发送端也可以重复最近的音频帧以增强抗丢失能力。

格式检查器可以确认“整数个 slice”“整数个 frame”和字段范围，却不知道路径 MTU 是否已变化、某片 IP 分片是否消失、重复音频是否可接受，或接收端能否维持连续的输出时钟。

时间戳是坐标，不是播放证明

RTP timestamp 是 32 位 90 kHz 时钟，代表 MPEG picture 的采样时间；属于同一 picture 的所有 RTP 包使用同一个值。Marker 位标记包含 picture 末尾的包。

两者都不能当作进度条。存在 B picture 时，picture 的传输顺序与呈现顺序不同，时间戳可以合法地非单调。只装 sequence、extension 或 GOP header 的包，还会借用下一幅 picture 的时间戳。序号回答“包以什么顺序发送”，时间戳回答“媒体属于哪个时间”，它们不是同一个轴。

Audio Offset 把音频放到这个时间坐标上。它是一个带符号的样本数，描述 audio frame 起点相对本包 RTP timestamp 的偏移。在 44.1 kHz 下，范围约为正负 750 毫秒；规范甚至承认，对每秒一帧之类的极低视频帧率，这个范围可能不够，格式可能无法使用。

有 B picture 时，音频不会随视频重新排序，而是按传输顺序装包，再靠 offset 指向正确的呈现关系。因此，一个数值正确的 offset 只是排程所需输入。它没有证明接收端采用了正确 picture 状态、音频样本被按时送出、两个设备时钟没有漂移，或人耳与人眼最终得到同步结果。

丢包让“可定位”与“已修复”彻底分开

RFC 2343 提供了实用的损伤坐标。序号与时间戳组合可发现丢包；slice number 与首个 macroblock 的位置可帮助估计损失范围。如果只丢了同一 picture 内的一些 slice，解码器可能继续工作，并用上一幅 picture 的像素填补缺口。音频侧也可注入背景噪声之类的替代 frame，以掩盖空洞并尽量维持 lip-sync。

这里没有任何一步恢复了原始信息。重复像素不是丢失像素，背景噪声不是原始声音。concealment 只会降低损伤的可见度，不会改变“数据已丢”的事实。

头部状态的风险更尖锐。N 位表示 sequence、extension、GOP 或 picture header 是否比此前发送的版本发生变化。若状态改变，接收端没有其他渠道取得头部时，规范建议删除数据直到新的 picture start。重度丢包时，可能要一直等到新的 sequence header。

BMPEG 没有纳入 RFC 2250 那类专门的 temporal-reference picture counter。GOP header 丢失可能不被发现，并在某些剪辑过的材料中让随后 B picture 错误解码。负载仍可能“可解析”，解码上下文却已经偏离。

封装之后至少还有七张回执

第一张回执是包是否完整、及时到达。第二张是组成 picture 所需的下层分片和 RTP 包是否齐全。第三张是解码器是否拥有正确的 sequence、GOP 与 picture 状态。第四张是音频与视频时钟是否把 timestamp 和 offset 换算成一致的呈现时刻。第五张是 renderer 是否生成有效 frame 与 sample。第六张是屏幕和音频路径是否真的输出，且没有静音、隐藏、后台暂停或设备故障。第七张才涉及观众是否在场、是否感知到可接受的节目。

早一层成功不能替后一层签字。RTP 本身不预留资源，也不保证实时服务质量。格式正确的包可能迟到；完整 picture 可能依赖已经丢失的旧状态；解码出的 frame 可能被丢弃；同步渲染可能发生在隐藏窗口；亮着的屏幕也可能面对一把空椅子。

RFC 2343 的历史意义正来自它把一层职责写得足够清楚：发送端怎样声明一组捆绑音画关系。边界因此也足够清楚——这是包装声明，不是播放见证。