如上一篇介绍RemoteBitrateEstimator有四个派生类WrappingBitrateEstimatorRemoteBitrateEstimatorAbsSendTimeRemoteBitrateEstimatorSingleStream和RemoteEstimatorProxyclass WrappingBitrateEstimator : public RemoteBitrateEstimator class RemoteBitrateEstimatorAbsSendTime : public RemoteBitrateEstimator class RemoteBitrateEstimatorSingleStream : public RemoteBitrateEstimator class RemoteEstimatorProxy : public RemoteBitrateEstimator一WrappingBitrateEstimator1.1 功能概略WrappingBitrateEstimator 是 ReceiveSideCongestionController 内部的一个适配器Wrapper类。它的核心目的是动态选择并代理具体的带宽估算器实现。由于 WebRTC 支持多种带宽估算策略主要是传统的基于到达时间的 REMB 和现代的基于发送时间戳的 TWCC/GBR这个类负责根据接收到的 RTP 包头部信息自动判断应该使用哪种估算器并将所有调用转发给当前选中的实例。WrappingBitrateEstimator 是一个智能代理。它监控流入的 RTP 流自动检测是否可以使用更高级的基于时间戳的带宽估算技术并动态切换底层的估算引擎从而为 WebRTC 提供最优的接收端带宽估计能力。1.2 核心职责策略切换1.2.1 WebRTC 的接收端带宽估算主要有两种模式1. 传统模式 (REMB): 依赖包到达时间间隔Inter-arrival time来估算网络拥塞。不需要发送端特殊支持。2. 现代模式 (Transport-wide CC / GBR): 依赖 RTP 头部扩展中的 Absolute Send Time (AST)。发送端在包中写入精确的发送时间接收端通过比较“发送时间”和“到达时间”来计算单向延迟OWD从而更准确地进行拥塞控制。1.2.2 WrappingBitrateEstimator 的作用就是• 初始时可能默认使用传统的估算器。• 当它检测到 incoming RTP 包中包含 Absolute Send Time 扩展头时它会切换到支持 AST 的估算器通常是 RemoteBitrateEstimatorSingleStream 的增强版或专门的处理逻辑。• 它确保上层代码无需关心底层具体用的是哪种算法只需调用统一的接口。1.3 为什么要这个派生类1. 兼容性: WebRTC 需要兼容旧版本的客户端不支持 AST和新版本的客户端支持 AST。这个类允许同一个连接在运行过程中平滑过渡或根据对端能力选择最佳策略。2. 解耦: ReceiveSideCongestionController 不需要知道具体有哪些估算器实现也不需要处理复杂的切换逻辑。它只与 WrappingBitrateEstimator 交互。3. 统一接口: 无论底层是简单的移动平均还是复杂的卡尔曼滤波对外都暴露标准的 RemoteBitrateEstimator 接口。二、RemoteBitrateEstimatorAbsSendTime2.1 功能概略RemoteBitrateEstimatorAbsSendTime 是 WebRTC 中一种基于 绝对发送时间Absolute Send Time, AST 的接收端带宽估算器。它是 RemoteBitrateEstimator 接口的具体实现之一主要用于实现 REMB (Receiver Estimated Maximum Bitrate) 机制。与传统的基于包到达间隔Inter-arrival time的估算器不同它利用 RTP 头部扩展中的 24 位绝对发送时间戳计算包的**单向传播延迟One-Way Delay**变化从而更准确地检测网络拥塞。RemoteBitrateEstimatorAbsSendTime 是 WebRTC 接收端拥塞控制的核心实现之一。它通过分析单向延迟趋势GCC 算法和测量探针簇吞吐量动态估算网络可用带宽并通过 REMB 反馈指导发送端调整视频码率以在避免拥塞的同时最大化视频质量。2.2 核心算法组件该类组合了 Google Congestion Control (GCC) 算法的几个核心模块2.2.1 inter_arrival (InterArrival):• 负责计算两组数据包之间的发送时间差和到达时间差。• 通过比较这两个差值计算出传播延迟梯度Propagation Delay Gradient。如果到达时间差大于发送时间差说明包在网络中排队了延迟增加。2.2.2 estimator (OveruseEstimator):• 通常是一个卡尔曼滤波器Kalman Filter。• 它对 InterArrival 计算出的延迟梯度进行平滑和趋势估计区分噪声和真实的延迟增长趋势。2.2.3 detector (OveruseDetector):• 状态机。根据 OveruseEstimator 的输出判断当前网络状态是1. Normal: 网络空闲或稳定。2. Overusing: 网络拥塞延迟持续增加。3. Underusing: 网络利用率不足延迟减小或非常低。2.2.4 remote_rate (AimdRateControl):• AIMD (Additive Increase Multiplicative Decrease) 速率控制器。• 根据 OveruseDetector 的状态调整估算的带宽1. 如果 Overusing乘以减小因子如 0.85快速降低码率。2. 如果 Normal线性增加码率探测可用带宽。3. 如果 Underusing保持或缓慢调整。2.3 工作流程2.3.1. 包到达 (IncomingPacket):• 从 RTP 头部提取 24 位的 Absolute Send Time。• 调用 IncomingPacketInfo。• 更新 InterArrival 模块计算延迟梯度。• 将数据喂给 OveruseEstimator 和 OveruseDetector。• 如果检测到状态变化如 Overuse通知 AimdRateControl 更新带宽。• 如果包属于探针序列将其存入 probes_ 列表。2.3.2. 定期处理 (Process):• 由 Module 接口定期调用例如每 500ms。• 超时检查: 调用 TimeoutStreams移除长时间未收到数据的 SSRC。• 探针处理: 调用 ProcessClusters。如果有完整的探针簇到达计算其吞吐量。如果吞吐量高于当前估算值则大幅提升估算带宽。• 触发回调: 如果带宽估算值发生显著变化通过 observer_-OnReceiveBitrateChanged 通知上层上层随后生成 RTCP REMB 包发送给发送端。2.3.3. 获取估算值 (LatestEstimate):返回 AimdRateControl 当前的估算比特率以及所有活跃流的 SSRC 列表。2.4 为什么使用 Absolute Send Time传统的 REMB 仅依赖接收端的时钟来计算包间隔。如果发送端和接收端时钟不同步或者存在复杂的 NAT/防火墙重排序传统方法可能不准确。 Absolute Send Time 由发送端写入代表了包离开发送端的精确时刻。接收端用 本地到达时间 - AST 得到单向延迟。单向延迟的变化是网络队列堆积的最直接证据因此基于 AST 的估算器通常比纯接收端估算器反应更快、更准确。三、RemoteBitrateEstimatorSingleStream3.1 功能概略RemoteBitrateEstimatorSingleStream 是 WebRTC 中用于**接收端带宽估计Receiver-side Bandwidth Estimation**的一个具体实现类。 顾名思义它的设计初衷是处理**单一流Single Stream**或独立处理每个流的拥塞控制逻辑而不是像 RemoteBitrateEstimatorAbsSendTime 那样将所有流聚合在一起进行全局估算。它通常作为旧版 REMBReceiver Estimated Maximum Bitrate机制的一部分或者在特定配置下用于多流场景中的独立流监控。RemoteBitrateEstimatorSingleStream 是一个基于每流独立监控的接收端带宽估算器。它通过为每个 SSRC 维护独立的拥塞检测状态并在发现任一流动拥塞时降低全局估算带宽来实现简单的多流拥塞控制。虽然其精度不如基于绝对发送时间的估算器但它结构简单兼容性好是 WebRTC 早期版本和多流独立控制策略的重要组成部分。在现代 WebRTC 中它正逐渐被更先进的 RemoteBitrateEstimatorAbsSendTime 或发送端带宽估计SendSideBandwidthEstimation所取代。3.2 核心职责• 独立流监控它为每个接收到的 SSRC同步源标识符维护独立的过用检测器Overuse Detector。这意味着每个视频/音频流的网络状况是单独分析的。• 带宽估算基于包的到达时间间隔Inter-arrival time和大小估算当前网络的可用带宽。• AIMD 控制使用加性增、乘性减Additive Increase Multiplicative Decrease算法来调整估算的比特率以应对网络拥塞。• 反馈生成当估算的带宽发生变化时通过 RemoteBitrateObserver 通知上层上层通常会据此生成 RTCP REMB 包发送给发送端。3.3 工作流程3.3.1. 数据包处理 (IncomingPacket)1. 查找/创建检测器: 根据 RTP 头中的 SSRC在 overuse_detectors_ 中查找对应的 Detector。如果不存在则创建一个新的。2. 更新统计: 将包的大小和时间戳传递给 incoming_bitrate_ 以更新实际接收码率。3. 过用检测:• 将包的到达时间和大小传递给该 SSRC 专属的 Detector。• Detector 内部计算延迟梯度判断网络是否处于 kNormal, kOverusing, 或 kUnderusing 状态。4. 触发更新: 如果检测到状态变化或者定期触发调用 UpdateEstimate。3.3.2 . 带宽更新 (UpdateEstimate)1. 收集状态: 遍历所有活跃的 Detector获取它们的拥塞状态。2. 决策:• 如果任何一个流报告 kOverusing拥塞则通知 remote_rate_ 降低带宽估算值Multiplicative Decrease。• 如果所有流都报告 kNormal 或 kUnderusing则通知 remote_rate_ 缓慢增加带宽估算值Additive Increase以探测更多可用带宽。3. 回调: 如果估算的带宽值发生了显著变化调用 observer_-OnReceiveBitrateChanged触发 REMB 包的发送。3.3.3. 定期处理 (Process)• 由 Module 接口定期调用例如每 500ms 或 1s。• 超时清理: 检查 overuse_detectors_ 中的流如果某个 SSRC 长时间没有收到数据包则将其从映射表中移除释放资源。• 强制更新: 即使没有新包到达也可能触发一次带宽估算的检查以确保状态的及时性。3.4 与 RemoteBitrateEstimatorAbsSendTime 的区别特性RemoteBitrateEstimatorSingleStreamRemoteBitrateEstimatorAbsSendTime检测粒度每流独立。每个 SSRC 有自己的延迟检测器。全局聚合。所有流共享一个延迟检测器。时间源仅依赖接收端时钟包到达间隔。依赖绝对发送时间AST扩展头计算单向延迟。准确性较低。受限于接收端时钟精度和包排序问题。较高。能更准确地反映网络队列堆积情况。适用场景旧版实现或不支持 AST 扩展的端点。现代 WebRTC 默认推荐支持 GCC 算法。探针支持通常不支持复杂的探针簇分析。支持探针簇Probe Clusters以快速探测带宽上限。四、RemoteEstimatorProxy4.1 功能概略RemoteEstimatorProxy 是 WebRTC 中用于**发送端带宽估计Send-Side Bandwidth Estimation, SS-BWE**的关键组件。虽然它继承自 RemoteBitrateEstimator但它并不在接收端计算带宽。相反它的职责是充当一个“代理”或“中继”负责收集接收到的 RTP 包的精确到达时间并将这些信息封装成 RTCP Transport Feedback (TWCC) 包发送回发送端。发送端利用这些高精度的时间戳来计算网络延迟和丢包从而进行更精准的拥塞控制。RemoteEstimatorProxy 是 WebRTC 现代拥塞控制架构中的数据采集器。它不猜测带宽而是精确地记录“什么包在什么时间到达”并通过高效的 RTCP TWCC 格式将这些数据反馈给发送端。它是实现 Google Congestion Control (GCC) 发送端版本的关键基础设施。4.2 核心职责从 REMB 到 TWCC 的桥梁• 传统模式 (REMB): 接收端自己估算带宽然后告诉发送端“你最多可以发这么多”。• 现代模式 (SS-BWE/TWCC): 接收端只负责报告“我什么时候收到了哪个包”发送端自己根据这些报告来估算带宽。• RemoteEstimatorProxy 就是实现现代模式的核心类。它实现了 RemoteBitrateEstimator 接口以便嵌入现有的架构但其内部逻辑完全是为了生成反馈包。4.3 工作流程4.3.1. 接收包 (IncomingPacket)1. 提取信息: 从 RTP 头部获取序列号和到达时间 (arrival_time_ms)。2. 解包裹: 使用 unwrapper_ 将 16 位序列号转换为 64 位唯一序列号。3. 存储: 将 序列号, 到达时间 存入 packet_arrival_times_ 地图。4. 清理: 如果地图过大可能会移除过旧的条目以节省内存。4.3.2. 定期处理 (Process)由 Module 接口定期调用例如每几十毫秒。1. 检查间隔: 判断距离上次发送反馈是否超过了 send_interval_ms_。2. 触发发送: 如果时间到了调用 SendPeriodicFeedbacks()。4.3.3. 构建并发送反馈 (SendPeriodicFeedbacks - BuildFeedbackPacket)1. 确定范围: 根据 back_window如过去 500ms确定需要报告的序列号范围 [start_seq, end_seq]。2. 构建 RTCP 包:• 创建 rtcp::TransportFeedback 对象。• 设置基础序列号 (base_sequence_number) 和参考时间。• 遍历 packet_arrival_times_ 中的相关条目。• 编码状态: 对于每个序列号标记它是“收到”还是“丢失”如果在范围内但不在地图中。• 编码时间戳: 对于收到的包计算其到达时间与参考时间的差值Delta并使用紧凑格式1 byte 或 2 bytes编码进包中。3. 发送: 通过 feedback_sender_-SendCombinedRtcpPacket 将构建好的包发送回对端。4. 更新状态: 递增 feedback_packet_count_更新 last_process_time_ms_。4.4 为什么要这个类1 高精度拥塞控制: 传统的 REMB 只能提供粗略的带宽上限。TWCC 提供了逐包的到达时间发送端可以计算出精确的单向延迟变化OWD Delay Variation。这使得发送端能够区分“队列堆积引起的延迟”和“路径改变引起的延迟”从而做出更智能的码率调整决策。2 解耦: 它将“收集数据”和“估算带宽”解耦。接收端只需忠实地记录时间复杂的估算逻辑全部移到发送端SendSideBandwidthEstimation。
webrtc QOS-RemoteBitrateEstimator接收端带宽估计-四个实例（2）
如上一篇介绍RemoteBitrateEstimator有四个派生类WrappingBitrateEstimatorRemoteBitrateEstimatorAbsSendTimeRemoteBitrateEstimatorSingleStream和RemoteEstimatorProxyclass WrappingBitrateEstimator : public RemoteBitrateEstimator class RemoteBitrateEstimatorAbsSendTime : public RemoteBitrateEstimator class RemoteBitrateEstimatorSingleStream : public RemoteBitrateEstimator class RemoteEstimatorProxy : public RemoteBitrateEstimator一WrappingBitrateEstimator1.1 功能概略WrappingBitrateEstimator 是 ReceiveSideCongestionController 内部的一个适配器Wrapper类。它的核心目的是动态选择并代理具体的带宽估算器实现。由于 WebRTC 支持多种带宽估算策略主要是传统的基于到达时间的 REMB 和现代的基于发送时间戳的 TWCC/GBR这个类负责根据接收到的 RTP 包头部信息自动判断应该使用哪种估算器并将所有调用转发给当前选中的实例。WrappingBitrateEstimator 是一个智能代理。它监控流入的 RTP 流自动检测是否可以使用更高级的基于时间戳的带宽估算技术并动态切换底层的估算引擎从而为 WebRTC 提供最优的接收端带宽估计能力。1.2 核心职责策略切换1.2.1 WebRTC 的接收端带宽估算主要有两种模式1. 传统模式 (REMB): 依赖包到达时间间隔Inter-arrival time来估算网络拥塞。不需要发送端特殊支持。2. 现代模式 (Transport-wide CC / GBR): 依赖 RTP 头部扩展中的 Absolute Send Time (AST)。发送端在包中写入精确的发送时间接收端通过比较“发送时间”和“到达时间”来计算单向延迟OWD从而更准确地进行拥塞控制。1.2.2 WrappingBitrateEstimator 的作用就是• 初始时可能默认使用传统的估算器。• 当它检测到 incoming RTP 包中包含 Absolute Send Time 扩展头时它会切换到支持 AST 的估算器通常是 RemoteBitrateEstimatorSingleStream 的增强版或专门的处理逻辑。• 它确保上层代码无需关心底层具体用的是哪种算法只需调用统一的接口。1.3 为什么要这个派生类1. 兼容性: WebRTC 需要兼容旧版本的客户端不支持 AST和新版本的客户端支持 AST。这个类允许同一个连接在运行过程中平滑过渡或根据对端能力选择最佳策略。2. 解耦: ReceiveSideCongestionController 不需要知道具体有哪些估算器实现也不需要处理复杂的切换逻辑。它只与 WrappingBitrateEstimator 交互。3. 统一接口: 无论底层是简单的移动平均还是复杂的卡尔曼滤波对外都暴露标准的 RemoteBitrateEstimator 接口。二、RemoteBitrateEstimatorAbsSendTime2.1 功能概略RemoteBitrateEstimatorAbsSendTime 是 WebRTC 中一种基于 绝对发送时间Absolute Send Time, AST 的接收端带宽估算器。它是 RemoteBitrateEstimator 接口的具体实现之一主要用于实现 REMB (Receiver Estimated Maximum Bitrate) 机制。与传统的基于包到达间隔Inter-arrival time的估算器不同它利用 RTP 头部扩展中的 24 位绝对发送时间戳计算包的**单向传播延迟One-Way Delay**变化从而更准确地检测网络拥塞。RemoteBitrateEstimatorAbsSendTime 是 WebRTC 接收端拥塞控制的核心实现之一。它通过分析单向延迟趋势GCC 算法和测量探针簇吞吐量动态估算网络可用带宽并通过 REMB 反馈指导发送端调整视频码率以在避免拥塞的同时最大化视频质量。2.2 核心算法组件该类组合了 Google Congestion Control (GCC) 算法的几个核心模块2.2.1 inter_arrival (InterArrival):• 负责计算两组数据包之间的发送时间差和到达时间差。• 通过比较这两个差值计算出传播延迟梯度Propagation Delay Gradient。如果到达时间差大于发送时间差说明包在网络中排队了延迟增加。2.2.2 estimator (OveruseEstimator):• 通常是一个卡尔曼滤波器Kalman Filter。• 它对 InterArrival 计算出的延迟梯度进行平滑和趋势估计区分噪声和真实的延迟增长趋势。2.2.3 detector (OveruseDetector):• 状态机。根据 OveruseEstimator 的输出判断当前网络状态是1. Normal: 网络空闲或稳定。2. Overusing: 网络拥塞延迟持续增加。3. Underusing: 网络利用率不足延迟减小或非常低。2.2.4 remote_rate (AimdRateControl):• AIMD (Additive Increase Multiplicative Decrease) 速率控制器。• 根据 OveruseDetector 的状态调整估算的带宽1. 如果 Overusing乘以减小因子如 0.85快速降低码率。2. 如果 Normal线性增加码率探测可用带宽。3. 如果 Underusing保持或缓慢调整。2.3 工作流程2.3.1. 包到达 (IncomingPacket):• 从 RTP 头部提取 24 位的 Absolute Send Time。• 调用 IncomingPacketInfo。• 更新 InterArrival 模块计算延迟梯度。• 将数据喂给 OveruseEstimator 和 OveruseDetector。• 如果检测到状态变化如 Overuse通知 AimdRateControl 更新带宽。• 如果包属于探针序列将其存入 probes_ 列表。2.3.2. 定期处理 (Process):• 由 Module 接口定期调用例如每 500ms。• 超时检查: 调用 TimeoutStreams移除长时间未收到数据的 SSRC。• 探针处理: 调用 ProcessClusters。如果有完整的探针簇到达计算其吞吐量。如果吞吐量高于当前估算值则大幅提升估算带宽。• 触发回调: 如果带宽估算值发生显著变化通过 observer_-OnReceiveBitrateChanged 通知上层上层随后生成 RTCP REMB 包发送给发送端。2.3.3. 获取估算值 (LatestEstimate):返回 AimdRateControl 当前的估算比特率以及所有活跃流的 SSRC 列表。2.4 为什么使用 Absolute Send Time传统的 REMB 仅依赖接收端的时钟来计算包间隔。如果发送端和接收端时钟不同步或者存在复杂的 NAT/防火墙重排序传统方法可能不准确。 Absolute Send Time 由发送端写入代表了包离开发送端的精确时刻。接收端用 本地到达时间 - AST 得到单向延迟。单向延迟的变化是网络队列堆积的最直接证据因此基于 AST 的估算器通常比纯接收端估算器反应更快、更准确。三、RemoteBitrateEstimatorSingleStream3.1 功能概略RemoteBitrateEstimatorSingleStream 是 WebRTC 中用于**接收端带宽估计Receiver-side Bandwidth Estimation**的一个具体实现类。 顾名思义它的设计初衷是处理**单一流Single Stream**或独立处理每个流的拥塞控制逻辑而不是像 RemoteBitrateEstimatorAbsSendTime 那样将所有流聚合在一起进行全局估算。它通常作为旧版 REMBReceiver Estimated Maximum Bitrate机制的一部分或者在特定配置下用于多流场景中的独立流监控。RemoteBitrateEstimatorSingleStream 是一个基于每流独立监控的接收端带宽估算器。它通过为每个 SSRC 维护独立的拥塞检测状态并在发现任一流动拥塞时降低全局估算带宽来实现简单的多流拥塞控制。虽然其精度不如基于绝对发送时间的估算器但它结构简单兼容性好是 WebRTC 早期版本和多流独立控制策略的重要组成部分。在现代 WebRTC 中它正逐渐被更先进的 RemoteBitrateEstimatorAbsSendTime 或发送端带宽估计SendSideBandwidthEstimation所取代。3.2 核心职责• 独立流监控它为每个接收到的 SSRC同步源标识符维护独立的过用检测器Overuse Detector。这意味着每个视频/音频流的网络状况是单独分析的。• 带宽估算基于包的到达时间间隔Inter-arrival time和大小估算当前网络的可用带宽。• AIMD 控制使用加性增、乘性减Additive Increase Multiplicative Decrease算法来调整估算的比特率以应对网络拥塞。• 反馈生成当估算的带宽发生变化时通过 RemoteBitrateObserver 通知上层上层通常会据此生成 RTCP REMB 包发送给发送端。3.3 工作流程3.3.1. 数据包处理 (IncomingPacket)1. 查找/创建检测器: 根据 RTP 头中的 SSRC在 overuse_detectors_ 中查找对应的 Detector。如果不存在则创建一个新的。2. 更新统计: 将包的大小和时间戳传递给 incoming_bitrate_ 以更新实际接收码率。3. 过用检测:• 将包的到达时间和大小传递给该 SSRC 专属的 Detector。• Detector 内部计算延迟梯度判断网络是否处于 kNormal, kOverusing, 或 kUnderusing 状态。4. 触发更新: 如果检测到状态变化或者定期触发调用 UpdateEstimate。3.3.2 . 带宽更新 (UpdateEstimate)1. 收集状态: 遍历所有活跃的 Detector获取它们的拥塞状态。2. 决策:• 如果任何一个流报告 kOverusing拥塞则通知 remote_rate_ 降低带宽估算值Multiplicative Decrease。• 如果所有流都报告 kNormal 或 kUnderusing则通知 remote_rate_ 缓慢增加带宽估算值Additive Increase以探测更多可用带宽。3. 回调: 如果估算的带宽值发生了显著变化调用 observer_-OnReceiveBitrateChanged触发 REMB 包的发送。3.3.3. 定期处理 (Process)• 由 Module 接口定期调用例如每 500ms 或 1s。• 超时清理: 检查 overuse_detectors_ 中的流如果某个 SSRC 长时间没有收到数据包则将其从映射表中移除释放资源。• 强制更新: 即使没有新包到达也可能触发一次带宽估算的检查以确保状态的及时性。3.4 与 RemoteBitrateEstimatorAbsSendTime 的区别特性RemoteBitrateEstimatorSingleStreamRemoteBitrateEstimatorAbsSendTime检测粒度每流独立。每个 SSRC 有自己的延迟检测器。全局聚合。所有流共享一个延迟检测器。时间源仅依赖接收端时钟包到达间隔。依赖绝对发送时间AST扩展头计算单向延迟。准确性较低。受限于接收端时钟精度和包排序问题。较高。能更准确地反映网络队列堆积情况。适用场景旧版实现或不支持 AST 扩展的端点。现代 WebRTC 默认推荐支持 GCC 算法。探针支持通常不支持复杂的探针簇分析。支持探针簇Probe Clusters以快速探测带宽上限。四、RemoteEstimatorProxy4.1 功能概略RemoteEstimatorProxy 是 WebRTC 中用于**发送端带宽估计Send-Side Bandwidth Estimation, SS-BWE**的关键组件。虽然它继承自 RemoteBitrateEstimator但它并不在接收端计算带宽。相反它的职责是充当一个“代理”或“中继”负责收集接收到的 RTP 包的精确到达时间并将这些信息封装成 RTCP Transport Feedback (TWCC) 包发送回发送端。发送端利用这些高精度的时间戳来计算网络延迟和丢包从而进行更精准的拥塞控制。RemoteEstimatorProxy 是 WebRTC 现代拥塞控制架构中的数据采集器。它不猜测带宽而是精确地记录“什么包在什么时间到达”并通过高效的 RTCP TWCC 格式将这些数据反馈给发送端。它是实现 Google Congestion Control (GCC) 发送端版本的关键基础设施。4.2 核心职责从 REMB 到 TWCC 的桥梁• 传统模式 (REMB): 接收端自己估算带宽然后告诉发送端“你最多可以发这么多”。• 现代模式 (SS-BWE/TWCC): 接收端只负责报告“我什么时候收到了哪个包”发送端自己根据这些报告来估算带宽。• RemoteEstimatorProxy 就是实现现代模式的核心类。它实现了 RemoteBitrateEstimator 接口以便嵌入现有的架构但其内部逻辑完全是为了生成反馈包。4.3 工作流程4.3.1. 接收包 (IncomingPacket)1. 提取信息: 从 RTP 头部获取序列号和到达时间 (arrival_time_ms)。2. 解包裹: 使用 unwrapper_ 将 16 位序列号转换为 64 位唯一序列号。3. 存储: 将 序列号, 到达时间 存入 packet_arrival_times_ 地图。4. 清理: 如果地图过大可能会移除过旧的条目以节省内存。4.3.2. 定期处理 (Process)由 Module 接口定期调用例如每几十毫秒。1. 检查间隔: 判断距离上次发送反馈是否超过了 send_interval_ms_。2. 触发发送: 如果时间到了调用 SendPeriodicFeedbacks()。4.3.3. 构建并发送反馈 (SendPeriodicFeedbacks - BuildFeedbackPacket)1. 确定范围: 根据 back_window如过去 500ms确定需要报告的序列号范围 [start_seq, end_seq]。2. 构建 RTCP 包:• 创建 rtcp::TransportFeedback 对象。• 设置基础序列号 (base_sequence_number) 和参考时间。• 遍历 packet_arrival_times_ 中的相关条目。• 编码状态: 对于每个序列号标记它是“收到”还是“丢失”如果在范围内但不在地图中。• 编码时间戳: 对于收到的包计算其到达时间与参考时间的差值Delta并使用紧凑格式1 byte 或 2 bytes编码进包中。3. 发送: 通过 feedback_sender_-SendCombinedRtcpPacket 将构建好的包发送回对端。4. 更新状态: 递增 feedback_packet_count_更新 last_process_time_ms_。4.4 为什么要这个类1 高精度拥塞控制: 传统的 REMB 只能提供粗略的带宽上限。TWCC 提供了逐包的到达时间发送端可以计算出精确的单向延迟变化OWD Delay Variation。这使得发送端能够区分“队列堆积引起的延迟”和“路径改变引起的延迟”从而做出更智能的码率调整决策。2 解耦: 它将“收集数据”和“估算带宽”解耦。接收端只需忠实地记录时间复杂的估算逻辑全部移到发送端SendSideBandwidthEstimation。
