帧引用查找 · 这帧依赖哪些帧 · 音视频与 WebRTC 详解

视频靠帧间预测压缩，一帧解码常依赖之前的帧。接收端必须理清这层依赖，才知道一帧能不能解、丢帧毁了哪些后续。这一章读 video_coding/rtp_frame_reference_finder.h，讲清帧引用怎么被还原、以及它如何决定丢包后的可解码性。

帧引用查找 · 这帧依赖哪些帧

帧组齐了，但还不能立即解码。因为视频压缩靠帧间预测——大多数帧只编码“和参考帧的差异”，解它必须先有参考帧。接收端得理清这层依赖关系，才知道一帧能不能解。干这个的是 RtpFrameReferenceFinder（modules/video_coding/rtp_frame_reference_finder.h）。

帧间预测：大多数帧是“差异”

先理解为什么有依赖。视频帧分两类：

关键帧（I 帧 / IDR） —— 自包含，不依赖任何其他帧，独立可解。但大（编码整幅画面）。
预测帧（P 帧） —— 只编码“和参考帧的差异”（帧间预测）。小得多（只存变化的部分），但依赖参考帧——参考帧没解出来，它就解不了。

视频高压缩率的秘密，正是“大多数帧只存差异”——但代价是帧与帧之间结成了依赖链**。** 一段视频通常是“1 个关键帧 + 一长串预测帧”，每个预测帧依赖前面的帧。这条依赖链就是视频对丢包格外敏感的根源：丢了链条中间的一帧，它后面所有依赖它的帧全都解不出来——哪怕那些帧的包完好无损地到了，也没用（参考断了）。这就是为什么视频丢包会出现“花屏一直持续到下一个关键帧”的现象：依赖链断在哪，画面就烂到哪，直到一个自包含的关键帧重新“接上”。

RtpFrameReferenceFinder：还原依赖

问题是：接收端怎么知道“这帧依赖哪些帧”？这信息藏在编解码器的比特流和 RTP 元数据里，RtpFrameReferenceFinder 负责把它还原出来：

对每个组好的帧，分析它的参考关系——它依赖哪些更早的帧（靠帧号、时间戳、以及编解码器 / SVC 的层结构信息）。
判断这帧的参考帧是否都已解码：是 → 这帧可解，放行给解码器；否 → 它依赖的帧还没到 / 丢了，先扣住（或标记不可解）。

RtpFrameReferenceFinder 是接收侧的“依赖裁判”——它决定每一帧此刻能不能解，从而挡住“参考帧缺失、解了也是花屏”的帧。 有了它，接收侧才能做出正确的丢包恢复决策：如果发现某帧的参考链断了（依赖的帧彻底丢了、重传也没救回），继续往下解只会一路花屏——不如果断请求一个关键帧（PLI），从头接上依赖链。反之，如果只是暂时缺帧、重传有望补上，就等一等。理清依赖，是“是等、是救、还是重来”这个决策的前提——下一章的丢包恢复，全靠它给的依赖信息。现代 WebRTC 还用“依赖描述符（Dependency Descriptor）”头扩展直接携带依赖信息，让这一步更准。

[1] libwebrtc 源码.modules/video_coding/rtp_frame_reference_finder.h、rtp_vp8_ref_finder.h 等。
[2] libwebrtc 源码.modules/video_coding/（依赖描述符处理）、api/video/（帧依赖结构）。
[3] IETF「Dependency Descriptor」RTP 头扩展。

帧引用查找 · 这帧依赖哪些帧