摘要

  • RFC 9627 为分层视频定义一种有目标的 RTCP 反馈命令，使接收端只请求所需层级的刷新，而不必像 Full Intra Request 那样刷新整个分层码流。
  • 命令源与目标 SSRC、负载类型、当前/目标层级和序列号能说明请求内容及重复关系；它们不能证明编码器接纳、刷新点发出、数据包到达、解码器升级或画面改善。
  • 完整收据必须连接能力协商、命令授权与校验、拥塞下的调度、编解码器特定刷新、接收端识别、解码状态和按时呈现。

在故障复盘里，控制面可能一片绿色：LRR 已发出，序列号连续，目标层合法，发送端也看到了消息。只有一个事实不配合——接收端始终停留在基础层。

这不是一个字段缺失的问题，而是多个事实被压进同一个“成功”。RFC 9627 定义 Layer Refresh Request，用来要求分层媒体发送端生成一个刷新点，使此前只能解码较低层的接收端有机会提升。命令的权威到“请求什么”为止；后面的每一步都需要新的观察者。

刷新的是依赖结构，不只是某一张大图

空间增强层通常同时依赖当前时刻的低层图像，以及本层较早的图像。刷新该层时，新图像只引用当前时刻的低层内容，不再引用本层旧图；编码器还要承诺，未来也不再把刷新点之前的本层图像用作参考。

没有被刷新的其他层仍可保留旧依赖。这正是 LRR 与 Full Intra Request 的区别。RFC 8082 阐明了分层编解码器的 FIR 语义；FIR 要求覆盖更完整的解码器状态，而 LRR 只为真正需要的层级转换支付编码与带宽成本。

时间层刷新也不是简单插入一个关键帧。目标时间层要改为只依赖更低时间层，并停止引用刷新点之前的本层图像。若码流本来就始终按时间嵌套，接收端随时可以开始更高时间层，无需额外 LRR。此时继续发请求，增加的是控制流量，不是新的可解码性。

因此，刷新完成的核心问题是：从这个点以后，接收端缺少的旧参考是否真的退出了依赖链。仅看到帧变大、码率上升或出现“intra”标签，都不足以统一回答这个问题。

当前层和目标层只是请求端的陈述

LRR 是 RTCP Payload-Specific Feedback，IANA 为其分配 FMT=10。一个反馈包可以携带多条 FCI，每条指向不同的媒体发送端 SSRC。公共头中的发送者 SSRC 表示命令来源；公共的媒体源字段不使用并置零，真正目标写在各 FCI 中。

TTID/TLID 表示目标时间层与空间/质量层。负载类型决定这些数字该按哪种编解码器映射解释。脱离当时协商与 payload-type 表，数值本身没有可移植语义。

C 位决定是否声明当前层。C=0 表示请求刷新至目标为止的所有层；C=1 时，CTID/CLID 表示接收端声称自己当前能解码的最高层，并把该层及以下排除在请求之外。目标在任何轴上都不能低于当前层，且至少一个轴必须升高；否则接收方必须丢弃该请求。

媒体发送端还必须验证负载类型与层级索引是否适用于正在发送的码流。格式正确，只能说明字节排列通过第一道门；它不能证明命令来源具有本地授权，也不能证明当前编码器配置仍有这个层。

更关键的是，CTID/CLID 是请求发出时的自报状态，不是事后读取的解码器证明。接收端可能准确报告，也可能状态已经变化。协议把陈述送达，不替陈述提供未来保证。

相同序列号意味着同一意图仍未关闭

LRR 序列号只有八位，其空间限定在一对“命令源 SSRC—命令目标 SSRC”中。新命令按模 256 加一；同一命令的重复发送不得加一；初始值任意。

这一可靠性模型来自 RFC 5104 的 FIR。请求方可以按 RTCP 时间规则重发未决命令；当它识别到完整刷新点，或识别到一个已尝试但被丢包损坏的刷新点时，应停止重复。之后若再次需要刷新，才产生新序列号。

所以，序列号很适合回答“这是旧请求的重试，还是新的转换意图”。它不是 ACK，也没有编码器接纳位、执行时间、刷新帧标识、交付结果或解码状态。三次相同序列的 LRR，仍只代表一个被重复表达的意图。

循环回绕还要求保留上下文。经过 256 个新命令，同一个数值会再次出现。若日志只留下 seq=8，没有会话、时间、源/目标、负载类型与层级 tuple，所谓“同一请求”无法成立。

“尽快发送”受拥塞预算约束

编码器收到有效 LRR 后必须尽快发送刷新点；但同一规范也要求遵守拥塞控制给出的带宽限制。刷新图像往往比普通图像更大，因而可能不能立刻发送。

这不是规范自相矛盾，而是两个控制面各守一条边界。接收端有权表达升级意图，正向路径的拥塞控制有权决定何时承担额外字节。产品若在“接纳请求”时就写入完成，会把最需要解释的等待状态抹掉。

至少应区分：已收到、无效、未授权、已接纳、等待预算、已调度、已编码、已发出、已到达、已识别、已解码、已呈现。拥塞下延迟可能完全合规，同时又无法满足业务时限；两者可以同时为真。

LRR 的触发原因也不能混用。RFC 9627 明确禁止把它作为丢包或图像损坏的反应，并建议使用 RFC 4585 的 Picture Loss Indication。LRR 表达的是接收行为主动变化，例如开始解码此前有意丢弃的层。把损失修复与主动升级放进同一信号，复盘时就无法解释重试到底为了什么。

每种编解码器有自己的完成条件

H.264 SVC 把层级拆成时间、依赖与质量标识。空间/质量刷新可能要求按解码顺序在所有相关层看到正确指示。若 PACSI 聚合了多个层的 NAL 单元，其中一个聚合指示未必足以证明每层都完成刷新。

所引 VP8 负载格式只支持时间可伸缩。Y 位可标出切换点，但它影响所有层，而不仅是请求层；一条狭窄命令可能产生更宽的发送成本。

H.265 结合时间嵌套标志与 NAL 类型。刷新可以一步完成，也可在多个时间层上渐进完成；IRAP 图像也能满足条件。等待一个抽象的“关键帧”事件，会同时漏掉正确实现并放过错误实现。

RFC 9628 为 VP9 定义 TID/SID，并建议响应包携带层级与参考信息，使解码器或选择性转发中间件能回溯依赖链。这揭示了通用证据要求：必须说明目标层为何已不再依赖接收端没有的内容。

LRR 的层级字段刻意与 RFC 9626 的 TID/LID 保持一致。帧标记能帮助观察刷新候选点，却不能证明因果。刷新点可能本来就会出现；标记可能正确而数据包未到；数据包可能完整而解码器没有采用。相邻机制不能互相借权。

来源