webrtc QOS-RemoteBitrateEstimator接收端带宽估计（1）

RemoteBitrateEstimator为webrtc的接收端带宽估计基类，它的主要职责是通过分析接收到的 RTP 数据包的到达时间、大小和序列号，估算当前网络下行链路的可用带宽，并将该估算值通过 RTCP 反馈包（REMB）发送给发送端，以便发送端调整视频码率。

RemoteBitrateEstimator是 WebRTC 接收端拥塞控制的大脑。它不直接发送数据，而是通过“监听” incoming 数据包的特征，推断网络的承载能力，并间接指导发送端“应该发多快”。它是实现自适应码率（Adaptive Bitrate）的关键组件之一，确保在网络波动时视频通话既能保持流畅又不造成严重拥塞。
注意：在现代 WebRTC 版本中，基于 REMB 的估计器正逐渐被基于 TWCC (Transport Feedback) 的发送端带宽估计（SendSideBandwidthEstimation）所取代或补充，因为后者能提供更精确的逐包延迟信息。但在许多兼容场景和音频流中，REMB 仍然在使用。

有四个派生类（WrappingBitrateEstimator，RemoteBitrateEstimatorAbsSendTime，RemoteBitrateEstimatorSingleStream和RemoteEstimatorProxy）：

一， 继承关系

class RemoteBitrateEstimator : public CallStatsObserver, public Module {

1.1 继承自 Module:

• 这意味着它是一个周期性运行的模块。WebRTC 的主循环会定期调用其 Process() 方法（虽然在这个头文件中未显示，但这是 Module 接口的要求），用于执行超时检查、状态清理或定期计算。
• kProcessIntervalMs = 500: 建议的处理间隔为 500 毫秒。

1.2 继承自 CallStatsObserver:

它可以接收来自底层的统计信息或回调（如 RTT 更新等），尽管在这个特定接口中主要体现为对数据包的处理。

二、主要函数接口

2.1 IncomingPacket(...)

这是最核心的输入接口。每收到一个 RTP 包，上层（通常是 RtpVideoStreamReceiver 或 AudioReceiveStream）都会调用此方法。
• 参数:
1. arrival_time_ms: 包到达接收端的系统时间戳。这是计算**到达时间间隔（Inter-arrival Time）**的关键，用于检测网络抖动和拥塞。
2. payload_size: 有效载荷大小（不含头部）。用于计算比特率。
3. header: RTP 头部，包含 SSRC、序列号、时间戳等信息。
• 内部逻辑:
1. 记录数据: 将包的到达时间和大小存入内部缓冲区或滑动窗口。
2. 过用检测 (Over-use Detection): 这是带宽估计的核心算法（如 Google Congestion Control, GCC 的一部分）。它会分析到达时间的趋势。如果包到达的间隔逐渐变大（即延迟增加），说明网络队列在堆积，发生了“过用”（Over-use）。
3. 更新估计: 如果检测到过用，算法会降低带宽估计值；如果检测到空闲（Under-use），则可能增加估计值。

2.2 LatestEstimate(...)

供上层查询当前的带宽估算结果。
• 输出:
1. bitrate_bps: 估算出的可用带宽（bits per second）。
2. ssrcs: 参与此次估算的所有流的 SSRC 列表。因为 REMB 通常是对一组流（例如同一个 PeerConnection 下的所有视频流）进行联合估计。
• 返回值:

true 表示存在有效的估算值，false 表示尚未收集足够的数据或估算无效。

2.3 RemoveStream(uint32_t ssrc)

当某个媒体流停止接收（例如用户关闭了摄像头或离开了会议）时调用。
• 作用: 清理该 SSRC 相关的历史数据，防止旧数据干扰后续的带宽估算。
• 超时机制: kStreamTimeOutMs = 2000。如果一个流在 2 秒内没有新数据包，也可能被内部自动移除。

2.4 SetMinBitrate(int min_bitrate_bps)

设置估算带宽的下限。
• 作用: 即使网络状况极差，估算器也不会返回低于此值的带宽。这保证了视频流不会完全停止发送，至少维持一个最低的可观质量（或黑屏保活）。

三 协作类

3.1 RemoteBitrateObserver:

• 这是一个回调接口。当 RemoteBitrateEstimator 计算出新的带宽估计值时，它会通过 OnReceiveBitrateChanged 通知观察者。
• 观察者通常是 Call 类或传输控制器，它们负责根据这个新带宽值生成 RTCP REMB 包并发送出去。

3.2 TransportFeedbackSenderInterface:

• 虽然在这个头文件中定义，但它更多与现代的 TWCC (Transport-wide Congestion Control) 相关。传统的 REMB 估算器可能不直接使用它，但现代的带宽估计架构可能会结合两者。

四 工作原理简述 (GCC 算法背景)

RemoteBitrateEstimator是一个抽象类，但其典型实现（如 RemoteBitrateEstimatorSingleStream 或 InterArrival 基于的实现）通常遵循以下逻辑：
1. 到达时间滤波器: 使用卡尔曼滤波或其他算法平滑包的到达时间，消除噪声。
2. 延迟梯度计算: 计算连续包之间的到达时间差与发送时间差的偏差。
3. 状态机:
• Normal: 网络正常，带宽估计保持不变或缓慢增加。
• Overusing: 检测到延迟持续增加，判定网络拥塞，大幅降低带宽估计。
• Underusing: 检测到延迟减小或空闲，尝试线性增加带宽估计以探测可用容量。