摘要

  • RFC 2448 让发送端依据编解码器含义，把高优先级（HP）信息更可靠地送达，同时让低优先级（LP）视频继续走普通路径。
  • HP 到达并不能证明 LP 到达、两路内容相互匹配、解码成功或画面及时显示。

压缩并没有让每个比特承担同样的责任。有些比特说明画面的结构或解码参数，另一些比特承载了大部分可见内容。网络只看到一个个数据包；如果它本身不区分优先级，就无法判断哪种丢失会对编解码器造成更大影响。

RFC 2448 因而把判断放在编码器或应用端。发送方把被认为不可或缺的信息划入 HP，把其余码流划为 LP。它可以先通过可靠传输发送 HP，再开始传送 LP；也可以用单独的 RTP 包承载 HP；还可以保留原始未分区码流、额外复制 HP，或在视频开始前把可复用的 HP 信息带外送达并缓存。优先级并非由网络提供，而是由发送方安排出不同的可靠性路径。

关键难题是分类。RFC 指出，识别 HP 依赖编码算法的语法与语义，没有一种通用办法可以覆盖所有码流。MPEG-2 示例展示了代价：只包含头部的 HP 通常不到视频数据的 2%；若加入 DC 系数，比例可升至约 40%，单靠 HP 也能得到某种程度可用的视频，但可靠传送的数据量随之显著增加。这些数字属于 RFC 的示例，并非所有视频的普遍测量。

先送 HP 可以降低它遭遇丢包的风险，却会增加启动等待。独立的 RTP HP 包可采用不同负载类型，同时与主视频流共享时间戳格式和 SSRC 空间。这些标识便于协调，不代表两条路径具有相同的交付保证。发送端还可以让原始流继续携带 HP，只在发生丢失时才依赖额外副本。若带外发送的是可重复使用的 HP 状态，时间戳可能没有意义；关键帧以及可用时的标记位，能帮助接收端判断这些状态应与哪一段 LP 相接。

于是，接收端需要证明的不只是“可靠传输已结束”：HP 是否属于当前编解码器版本，是否对应 LP 流中的正确位置；必要的 LP 数据是否到达；解码器是否在播放期限前生成输出；输出是否真的进入显示环节。HP 的完整回执不能替代这些证据。

RFC 2448 于 1998 年 11 月发布，性质为 Informational，并非互联网标准。它提到 AT&T/Lucent 相关专利，并说明 IESG 与 IETF 不对专利的有效性、范围或许可可得性表态。文档描述了一种技术，不等于证明其被采用、现今部署、互操作或产生了观众收益。它的历史意义在于：选择性可靠性把传输问题变成编解码策略；每多一条路径，就多出一个必须验证的拼接条件。

来源

RFC 2448；RFC 2448 记录；IETF Datatracker 记录；RFC 2448 勘误；RFC 2250：MPEG 的 RTP 负载格式；RFC 3550：RTP；RFC 2198：冗余音频数据；RFC 2733：RTP 前向纠错；RFC 5109：RTP 通用 FEC；RFC 4588：RTP 重传；RFC 1191：路径 MTU 发现；RFC 1889：早期 RTP 规范；Heng Lu：运行代码优先；Heng Lu：规范与自愿采用。