RTCP 反馈 · NACK / PLI / REMB
除了周期性报告，RTCP 还有一类主动的反馈报文：请求重传（NACK）、请求关键帧（PLI/FIR）、报告估计带宽（REMB）。这一章读 rtcp_packet/ 下的 Nack/Pli/TransportFeedback，讲清 RTPFB 与 PSFB 两大类反馈，它们是让接收端「指挥」发送端的通道。
RTCP 反馈 · NACK / PLI / REMB
SR/RR 是周期性的统计报告，但 RTCP 还有一类更主动的报文——反馈（feedback）：接收端用它实时指挥发送端「重发那个丢了的包」「给我一个关键帧」「你最多发这么快」。这一章看这些反馈报文，它们是接收端影响发送端行为的通道。
两大类：RTPFB 与 PSFB
RTCP 反馈报文分两大类（RFC 4585），modules/rtp_rtcp/source/rtcp_packet/ 下的类名直接体现了这个分类：
反馈分两类：传输层反馈（RTPFB）和负载相关反馈（PSFB）。
- RTPFB（Transport-layer Feedback，
Rtpfb基类） —— 和传输有关，不关心媒体内容。典型：NACK（某些序号的包丢了，请重传）、Transport-CC 反馈（报告每个包的到达时间）。 - PSFB（Payload-Specific Feedback，
Psfb基类） —— 和媒体负载有关，通常是视频特有。典型：PLI / FIR（请求一个关键帧）、REMB（报告接收端估计的最大码率）。
源码里看得清清楚楚（modules/rtp_rtcp/source/rtcp_packet/）：
class Nack : public Rtpfb { ... }; // 传输层:请求重传
class TransportFeedback : public Rtpfb { ... }; // 传输层:到达时间反馈
class Pli : public Psfb { ... }; // 负载相关:请求关键帧三个最重要的反馈
具体到 WebRTC 天天在用的：
| 反馈 | 类 | 接收端想说 | 发送端的反应 |
|---|---|---|---|
| NACK | Nack(RTPFB) | 「序号 X 的包我没收到」 | 从历史重传那个包 |
| PLI | Pli(PSFB) | 「我解不了了，给个关键帧」 | 让编码器立即产一个关键帧 |
| Transport-CC | TransportFeedback(RTPFB) | 「这些包我在这些时刻收到了」 | 喂给拥塞控制估带宽 |
- NACK（下一章细讲）是丢包重传的触发器：接收端发现序号缺了，发 NACK，发送端重发。
- PLI（Picture Loss Indication） 是视频特有的救命稻草：视频靠帧间预测，一旦丢包导致后续帧解不出（参考帧没了），接收端发 PLI 请求一个不依赖任何历史的关键帧，从它开始重新解码。FIR（Full Intra Request）类似。
- Transport-CC（第 5 部分详解）是现代拥塞控制的反馈通道，报告每个包的精确到达时间。
REMB 与 Transport-CC：两代带宽反馈
带宽反馈有过两代，读老代码会都见到：
- REMB(Receiver Estimated Max Bitrate) —— 老方案。接收端自己估算「我这边看能收多快」，通过 REMB（一种 PSFB）把这个数字告诉发送端，发送端照着发。带宽估计在接收端做。
- Transport-CC —— 新方案。接收端只报原始数据（每个包何时到达），把带宽估计的活儿挪到发送端做（第 5 部分）。发送端信息更全（它知道自己何时发的），估得更准。
从 REMB 到 Transport-CC，是 WebRTC 拥塞控制的一次重要演进：把「估带宽」从接收端搬到了发送端。 为什么？因为发送端同时掌握发送时间和（经反馈得到的）到达时间，能算出精确的单向延迟变化——这是延迟based 带宽估计的核心信号；而接收端只知道到达时间，信息不全。这个「让信息最全的一方做决策」的思路，是分布式系统设计的常见智慧。现代 WebRTC 默认 Transport-CC，REMB 仅作兼容退路。这也是为什么 transport-cc 序号那个头扩展如此关键——它是这套新反馈的载体。
小结与下一章
RTCP 反馈让接收端主动指挥发送端，分两类：RTPFB（传输层，Rtpfb 基类：NACK 请求重传、Transport-CC 报到达时间）和 PSFB（负载相关，Psfb 基类：PLI/FIR 请求关键帧、REMB 报码率）。三个最常用：NACK（重传）、PLI（要关键帧）、Transport-CC（带宽反馈）。带宽反馈从 REMB（接收端估）演进到 Transport-CC（发送端估，信息更全）。
NACK 是可靠性的核心——它触发的重传怎么做？为什么常走独立的 RTX 流？下一章专讲。👉 NACK 与 RTX 重传。
参考资料
- [1] libwebrtc 源码.
modules/rtp_rtcp/source/rtcp_packet/nack.h、pli.h、transport_feedback.h、remb.h（Rtpfb/Psfb基类）。 - [2] IETF RFC 4585「RTP/AVPF 反馈」、RFC 5104「Codec Control Messages（PLI/FIR）」。
- [3] IETF「transport-wide-cc」草案、REMB 草案。