摘要

  • RFC 3016 不只是规定怎样把 MPEG-4 Audio/Visual 放进 RTP；它把编码边界映射成网络故障边界：合并越多，头部开销越小，一次丢包同时带走的独立单元也越多。
  • RTP 序号、时间戳与 marker 只描述运输结构。它们不能证明配置仍在、解码成功、画面显示，或者人已经听见与看见。

故障报告看上去并不严重：只丢了一个 RTP 包。编码器没有报警，Profile 和 Level 匹配，后续序号继续递增。可是接收端冻结的画面远比“一个包”大。

问题出在“一个包”并不是稳定的媒体单位。它是发送端做出的装箱决定。

2000 年 11 月发布的 RFC 3016，标题是 RTP Payload Format for MPEG-4 Audio/Visual Streams。它让 MPEG-4 Audio 与 Visual 基本流不经 MPEG-4 Systems 的同步和流管理层，直接映射到 RTP。H.323 可以用 H.245 管理，SIP 与 RTSP 可以用 MIME 和 SDP 描述。MPEG-4 于是能同其他 RTP 编解码格式使用相似的会话工具。

少一层系统，并不等于少一层责任。配置放在哪里、语法从哪里开始、怎样避开路径 MTU、几个恢复单元共同承担一次网络丢失，都必须由封包器作出选择。

编码边界、封包边界与丢包边界

MPEG-4 Visual 自己带有错误恢复工具。RFC 3016 因此没有再加媒体专用 RTP 头，而是把按字节对齐的 Visual bitstream 直接写入 payload，也不删除其中的语法元素。

“直接”仍有严格次序。配置与 Group_of_VideoObjectPlane 字段必须位于 RTP payload 开头，或者紧跟在语法层级更高的头部之后。只要 payload 中出现头部，它就必须从最高层的头部开始。任何头部都不得跨两个 RTP 包。

这些规则保护的是重新获得解释能力的起点。若一个头部被切成两半，两个数据报就同时成为理解后续内容的前提；丢失任意一个，后面仍到达的字节也可能失去意义。

RFC 3016 建议一只 video packet 对应一只 RTP packet，并把大小调到不超过 Path MTU。在丢包较多的网络上，这能缩小损坏范围：即使装有 VOP 头的 RTP 包丢失，其他 video packet 仍可能凭自身的 Header Extension Code 解码。

但标准没有把“一对一”写成永恒禁令。低码率下，小 video packet 周围的 RTP/IP 头部显得昂贵，多个单元可以合并进同一 RTP 包。代价同样写得清楚：这一只 RTP 包丢失时，里面的多个 video packet 会一起被丢弃。

于是，节省头部就是扩大一次下注的筹码。网络统计只记一只包，媒体层可能失去三块原本互不依赖的内容。

两只包的数量相同，恢复能力却不同

RFC 3016 的一个禁止示例尤其重要。两个逻辑 video packet 都可以分布在两只 RTP packet 中。在正确布局里，第二只 RTP 丢失，只影响第二个视频单元；在错误布局里，第一个单元跨过边界，第二个单元的头又排在它后面，第二只 RTP 一旦丢失，两个单元都无法使用。

线上仍然是两只包，丢失仍然是一只。变化的只是依赖关系放在了哪里。

这说明丢包率不等于媒体损失率。序号缺口能指出运输层少了一件货，却不能告诉运营者，那件货是普通片段、多个合并单元、随机接入头，还是后续内容依赖的配置。

当编码器关闭 video packet 时，VOP 可以在任意字节位置切开。对于被保证无错的网络，固定长度切片可能可用；在易丢包网络上，RFC 3016 明确认为这种做法恢复性很差。格式合法并不能替部署证明“这里不会丢”。

Marker 是句号，不是收据

在 Visual 映射中，marker bit 标记 VOP 的最后一只或唯一一只 RTP 包。若多只 VOP 共用一个 payload，marker 也置位；RTP 时间戳指向其中最早的 VOP，后续时间需要从 VOP 内部头部推导。

它能帮助拆包，却不能替接收端签收。带 marker 的包可能根本没到；它可能到达时前一片已经丢失；拆包器可能完成组合而解码器拒绝；解码器可能产出图像而应用没有显示。

RTP 的通用语义也保留了边界。序号帮助发现丢失和恢复发送顺序。时间戳表达采样时刻，用于同步与抖动计算；真正播放发生在接收端更晚的位置。marker 的含义由 payload profile 指定，它从来不是通用的“已播放”位。

Audio 的配置先丢，声音后失效

MPEG-4 Audio 使用 LATM。完整或部分 audioMuxElement 直接进入 RTP payload，第一个字节必须占据 payload 的第一个位置。标准建议一只 element 一只包；若超过 Path MTU，则允许跨包分片。

更隐蔽的依赖来自 StreamMuxConfig。在 in-band 模式中，useSameStreamMux 可以表示继续沿用上一帧的配置。少发一份配置能省带宽；若上一帧丢失，当前帧即使完整到达，也可能无法解码。因此 RFC 3016 建议按照网络状况重复发送配置。

重复间隔实质上是一段风险窗口。间隔越长，一次配置丢失影响的后续媒体越多。Out-of-band 模式可以通过 SDP 的 config 参数传送配置，但责任只是转移给信令：接收端仍需拿到正确版本，并把它同正确的流关联。

“后面的包都到了”因此不足以说明媒体可用。地图可能在前一只包里。

能力表与当前配置是两份证据

RFC 3016 注册了 video/MP4V-ES 与 audio/MP4A-LATM。对于 Visual，profile-level-id 可表示编解码器能够支持的 Profile/Level 组合；config 则描述对应 bitstream 的实际配置，并被明确禁止用作能力声明。

一个接收器可能具备通用工具，却没有当前流的参数。两个端点可能宣称同一 Profile/Level，却对当前配置理解不同。SDP 可以正确描述意图，但它不观察路上实际到达的字节，更不能证明解码结果。

能力、配置、运输、解码、显示，是五层证据，不是一盏绿灯。

FEC 接手时，赌注早已装好

RFC 3016 允许使用 RFC 2733 的通用前向纠错和 RFC 2198 的冗余音频。它们能提高恢复机会，但开始工作时，source packet 里放什么已经由封包器决定。

这也是本文同 RFC 2733 历史文章的边界。后者讨论奇偶校验怎样保护和重建丢失的 RTP 包，以及带宽、延迟和恢复条件；RFC 3016 暴露的是更早一步：每个被保护的包里，到底捆绑了多少语法单元和配置依赖。

RFC 2429 的 H.263+ 方案提供另一种对照：它加了 payload header，并在适当时复制 picture header 信息，使原头部丢失后仍有机会解码。RFC 3016 则依赖 MPEG-4 Visual 内建的恢复语法。共同的 RTP 外壳没有抹平编解码格式的恢复契约。

后来的 RFC 揭开了版本标签的局限

2011 年的 RFC 6416 废止了 RFC 3016，主要修正 MPEG-4 Audio 同 3GPP PSS 的错位。新版要求的 LATM 版本同 2000 年文本引用的版本并不二进制兼容，并更新了 StreamMuxConfig、SBR、参数立体声、rate、声道与可伸缩层信令。

有些自称实现 RFC 3016 的产品已经使用较新的 LATM，可能更接近 RFC 6416，恰恰没有严格实现旧文本。RFC 号只是标签；互通需要具体 bitstream 和信令版本的证据。

RFC 6416 仍保留 Visual 的核心取舍：一只 video packet 单独成包有利于隔离损失；合并能省头部，却让一次丢包带走更多内容。

加密不能缩小同一只包里的命运共同体

RFC 3016 继承 RTP 安全考虑，指出压缩媒体可以在压缩后加密。这个直接 payload 只承载音视频，不包含完整 MPEG-4 Systems 可携带的 MPEG-J applet 与脚本。

机密性、完整性、源认证能保护内容与来源，却不能改变 Path MTU，不能补回丢失配置，也不会自动拆开一只包里的多个恢复单元。一只真实且未被篡改的包，仍可能是过大的故障单位。

RFC 3016 的历史意义正在这里：封包不是把编码结果装进“透明信封”。它把编码语法投射成网络故障域。编码器可以完全正常，而封包器已经决定，一次丢包究竟只毁掉一片，还是把后面的解释地图也一起带走。

来源