摘要

  • RTCP 应答若被延后，接收端必须依据发送时仍在状态窗口里的帧作答；对 1—4 的请求，完全可能合法地只返回 3—4。
  • 这不是接收端改变历史，而是两个时点的可见状态不同。可靠记录必须同时保留请求、应答、窗口边界、SSRC 时代与后续解码和恢复结果。

控制端在时刻 A 请求了 Frame ID 1 到 4 的状态。应答受 RTCP 调度约束，没有立即发出。视频继续到达，接收端的有限窗口从 1—4 推进到 3—6。等到时刻 B 真正构造消息时，它只返回了 3 和 4。

一种监控系统把缺少的 1 和 2 标成丢包；另一种系统把它们标成已确认，因为应答起点已经前移。草案支持的结论更窄：在应答发送时，1 和 2 的逐帧状态已经不在接收端保留窗口内。

这份题为 RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement 的文件，是 AVTCORE 工作组的活跃 Internet-Draft。本文冻结的 revision 01 日期为 2026 年 7 月 6 日，2027 年 1 月 7 日到期，预期状态为 Informational。Datatracker 状态是 I-D Exists，尚无 shepherd、负责的 Area Director、IESG 评估、RFC 编号或完成的 IANA 分配。RTCP 消息使用 PT 205，FMT 仍为 TBD，文件建议值 12。它定义的是候选机制，不是部署、互通或效果证明。

一个比特承载的是协调语义

草案使用 16 位 Frame ID。每个被标记的帧按发送顺序递增一，溢出后回到零，接收端必须接受任意起点。RTP 头扩展应该出现在视频帧最后一个包上，同一帧不得出现超过一次。

此处“帧”的含义并不等于屏幕上的一幅画面。它是会更新后续单元可引用之编解码状态的可解码比特流单元，通常是完整帧，也可能是不展示的 frame、独立 tile 或 slice。因此，即使某个 Frame ID 得到正面状态，也不能直接推出用户看见了一幅图像。

头扩展中的 FFR 取值 00 只携带 Frame ID；01 同时隐含请求当前单帧状态；10 另带独立的 Feedback Start 与 Feedback Length；11 保留。RTCP 应答包含重同步 R 标志、16 位起点、8 位长度和逐帧一比特状态。

状态一不是单义的“解码完成”。它表示已收到，并且已经解码或将会解码。为降低反馈延迟，接收端可在解码尚未结束时给出一，只要保证会尝试解码。若之后失败，即使失败单元来自可丢弃层，也必须请求关键帧。状态零同样合并了未收到、未解码和不准备解码三种情况。

协议为了低开销而压缩语义。数据分析不能再把被压缩掉的区别凭空补回来。

状态窗口是一段会移动的现在

接收端维护连续的滑动状态窗口，默认容纳 255 个 Frame ID；协商值可以是 1 到 32767。由于单个 RTCP 消息的 Length 只有八位，窗口超过 255 时需要多条消息。新 Frame ID 推动窗口越界后，最旧条目按 FIFO 丢弃。

若请求范围只有一部分仍在窗口内，应答会把 Start 向前移到最旧的可用条目，仅返回交集。若完全没有交集，就保留被请求的起点并返回 Length 0。发送端看到起点前移或零长度后，不得再把已丢弃的旧状态对应帧当作可靠引用。

零长度既不证明丢失，也不证明成功；它证明的是“被问到的逐帧状态已不再保留”。新的 Feedback Start 还能隐式确认并清退更旧状态。这是协议生命周期控制，不是为更旧帧补发的一批解码证书。

在开头的例子里，应答应记录为两个时间事实：请求在 A 时刻覆盖 1—4；消息在 B 时刻依据 3—6 的窗口生成，并返回 3—4。只有保留这两个时点，分析者才能知道差异来自合法的窗口推进，而非链路篡改或接收端自相矛盾。

后来的请求可以取代先前请求

RTCP 反馈可能因规则而延迟。草案还规定，如果较新请求在旧请求的待发应答之前到达，接收端应该丢弃旧请求，只回答最新请求。这样可以避免控制消息排队，阻止过时反馈继续占用带宽。

代价是：收到一条请求，并不等于承诺日后会按原范围单独作答。日志若只记“请求已到达”和最终一条应答，就可能把被取代的范围误判为无响应。

最小可追溯记录需要请求所依附的当前 Frame ID、请求范围、到达时间、是否被更新请求取代、应答构造与发送时间，以及当时窗口上下界。包到达顺序、Frame ID 发送顺序、请求处理顺序、解码完成顺序和引用依赖关系，是五条不同的时间轴。

网络乱序、重传或 FEC 恢复还会让旧请求晚于新请求出现。接收端仍保存当前 Frame ID 的接收状态，但若已经处理过依附于更新 Frame ID 的请求，就忽略这个旧请求。按数据包到达时间重排控制历史，会把正确的防倒退规则误报成漏答。

重同步权力跨越两个端点

R 标志用于请求重同步。接收端可以指出最新成功解码的 Frame ID，并在长度允许时一直报告到最新收到的 Frame ID。这回答了“接收端认为哪个引用良好”。

发送端还必须回答另一个问题：那个引用是否仍在编码器自己的引用缓冲区里。若在，应从这个引用或另一个已知接收端拥有的引用继续编码；若不在，应该发送关键帧。接收端解码过与发送端仍保留，是两份独立状态。

随后还存在完整执行链：选择引用、生成恢复帧、封包、发送、到达、重组、解码、渲染。最初的反馈位不证明这些步骤。resync-timeout 可在 1 到 65535 毫秒之间表达解码饥饿触发阈值，不是恢复完成时限。status-window-size 约束接收端记忆，也不保证发送端引用缓冲区同样深。

SSRC、依赖链与中间盒都改变证据边界

Frame ID 与反馈状态只在一对发送端/接收端 SSRC 中唯一。任一 SSRC 变化，序列重启，旧状态全部丢弃；除此以外不允许无故缺口或重置。只凭数值相同把两个时代的 Frame ID 连接起来，会制造不存在的连续性。

同一 SSRC 中还可能交错 simulcast 或其他独立依赖链。一条链上较晚帧解码成功，不足以证明另一条链上较早帧的状态。范围与向量的意义，正是保留“最大值”无法表达的空洞。

SFU 或 SFM 可能重写 Frame ID，使每个下行接收端看到连续序列。草案说，中间盒通常应等所有活跃接收端都确认后再向上游确认。这里的“所有活跃”必须成为可审计的分母：包括当时成员、每条下行与上游 ID 映射、各自状态和聚合时刻。缺少分母的上游一位确认，不能证明某个具体接收端，更不能证明观看结果。

SDP 中声明头扩展 URI 和 rtcp-fb 只是能力协商。它不证明某个请求真正发出、窗口实际保留、帧完成解码或会话恢复。能力、执行和结果必须分别记录。

不要把两个时点压成一个结论

Heng Lu 的现实分层提供了清晰边界：Frame ID、请求范围和反馈向量是符号性协调；窗口与引用缓冲区是会变化的可执行状态；包送达、解码完成、画面呈现和观看体验则属于后续观察。

最小初始规范不必统一每种编解码器，却应统一证据封套：SSRC 对、时代、Frame ID、FFR、请求范围、请求到达时刻、应答发送时刻、窗口边界、逐位语义、R 标志、接收端引用、发送端引用可用性与后续动作。无法从该层获知的结果，应明确写成未知。

运行代码优先意味着主动制造时间错位：延迟 RTCP 直到窗口前移，连续提交新旧请求，让 16 位编号回绕，在正面反馈后强制解码失败，更换 SSRC，交错两条依赖链，逐出发送端引用，并改变 SFU 活跃成员。系统若只能验证同步、低延迟的顺利路径，就没有验证这份草案最重要的边界。

对 1—4 的请求最终只得到 3—4，不是历史被篡改。它揭示的是一个更基本的事实：任何状态回答都属于一个时间点。治理良好的系统不要求接收端假装记得已经清退的内容，也不会用发送时的现在去伪造请求时的过去。

Sources