webrtc中rtcp反馈与码率控制模块分析

本文分析了WebRTC发送端如何根据RTCP反馈信息进行码率调整。当RTCP接收报告包到达时,经过处理触发_RtcpBandwidthObserver,计算带宽参数并调用bitratecontrolImpl进行带宽评估。重点讨论了HandleReportBlock中的RTT计算,UpdateMinHistory的变量更新,以及UpdateEstimate在带宽估计中的作用。

webrtc中rtcp反馈与码率控制模块分析

0. 参考文档

1 google congestion control

1. 简介

webrtc的带宽估计分为两部分,一部分为发送端根据rtcp反馈信息进行反馈,另一部分为接收端根据收到的rtp数据进行相应的码率估计[1]。
本文先分析发送端根据rtcp反馈信息进行码率调整的部分代码。

具体计算公式:

2. 代码结构

2.1 类关系

rtp_stream_receiver中有一个继承自抽象类RtpRtcp的ModuleRtpRtcpImpl,ModuleRtpRtcpImpl中有一个rtcp_receiver。当有RTCP包到来时,逐层处理至rtcp_receiver,当包是rtcp receiver report包,则会将包解析,然后在ModuleRtpRtcpImpl中再次调用rtcp_receiver中的TriggerCallbacksFromRTCPPacket函数,触发对应rtcp的一些事件,反馈触发的主要是_cbRtcpBandwidthObserver的观察者(RtcpBandwidthObserverImpl),这个观察者收到对应的report block之后会计算成带宽估计所需要的参数,并调用属主bitratecontrolImpl类对带宽进行估计,这里会调用SendSideBandwidthEstimation中的UpdateReceiverBlock进行实际的带宽评估。

2.2 调用关系图

3. 代码分析

3.1 HandleReportBlock

这个函数中最主要的部分就是RTT的计算,webrtc中对于RTT平滑的因子是一个线性增长的因子。

/* 这个函数根据对应的report block生成了一个新的RTCPReportBlockInformation结构体,
 * 并计算出对应的RTT,多report block在调用点处执行循环。  */
void RTCPReceiver::HandleReportBlock(
    const RTCPUtility::RTCPPacket& rtcpPacket,
    RTCPPacketInformation& rtcpPacketInformation,
    uint32_t remoteSSRC)
    EXCLUSIVE_LOCKS_REQUIRED(_criticalSectionRTCPReceiver) {
  // This will be called once per report block in the RTCP packet.
  // We filter out all report blocks that are not for us.
  // Each packet has max 31 RR blocks.
  //
  // We can calc RTT if we send a send report and get a report block back.

  // |rtcpPacket.ReportBlockItem.SSRC| is the SSRC identifier of the source to
  // which the information in this reception report block pertains.

  // Filter out all report blocks that are not for us.
  if (registered_ssrcs_.find(rtcpPacket.ReportBlockItem.SSRC) ==
      registered_ssrcs_.end()) {
    // This block is not for us ignore it.
    return;
  }

  RTCPReportBlockInformation* reportBlock =
      CreateOrGetReportBlockInformation(remoteSSRC,
                                        rtcpPacket.ReportBlockItem.SSRC);
  if (reportBlock == NULL) {
    LOG(LS_WARNING) << "Failed to CreateReportBlockInformation("
        
<think>我们正在讨论WebRTC中的REMB算法,特别是它是否使用丢包率来计算码率。首先,我们需要了解REMB算法。 REMB(Receiver Estimated Maximum Bitrate)是WebRTC中由接收端估算最大可用带宽并反馈给发送端的一种机制。在WebRTC中,带宽估计是一个复杂的过程,涉及多个因素,其中丢包率是一个重要指标,但REMB本身并不直接使用丢包率来计算码率。 根据WebRTC的架构,带宽估计主要由两部分组成: 1. 基于延迟的拥塞控制(如GoogCC算法):通过分析数据包之间的延迟变化来推断网络拥塞情况,从而调整发送码率。 2. 基于丢包的拥塞控制:当网络发生丢包时,会认为网络出现拥塞,从而降低发送码率。 但是,REMB消息本身并不包含丢包率的信息。REMB消息是接收端通过RTCP反馈的一种消息,它包含一个由接收端估算的带宽值(以bps为单位)。这个估算值是由接收端基于接收到的数据包的时间间隔、数据包大小等信息,通过特定的带宽估计算法(如Google的接收端带宽估计算法)计算出来的。 在WebRTC的实现中,接收端的带宽估计算法(如接收端使用的到达时间模型)主要关注的是延迟梯度(即包组之间的时间间隔变化),而不是丢包率。丢包率通常用于发送端的拥塞控制模块,当检测到丢包超过一定阈值时,发送端会主动降低发送码率。 因此,REMB算法本身并不直接使用丢包率来计算带宽估计值。丢包率是在发送端用于调整码率的另一个独立因素。 然而,在发送端,当它接收到REMB消息时,会结合其他信息(包括丢包率)来最终确定发送码率。发送端可能会将REMB建议的带宽值作为上限,同时根据丢包情况进一步调整。 总结: - 接收端在计算REMB(即最大可用带宽估计)时,主要基于延迟变化(即拥塞信号),不使用丢包率。 - 丢包率是发送端在拥塞控制中独立使用的另一个信号,用于在检测到丢包时调整发送码率。 引用说明: 根据WebRTC的文档和相关源码[^1][^2],REMB消息的生成仅基于延迟梯度,而丢包率则用于发送端的基于丢包的拥塞控制模块。 §§相关问题§§ 1. WebRTC中除了REMB,还有哪些带宽估计算法? 2. 发送端如何处理REMB消息和丢包率信息? 3. 在WebRTC中,丢包率是如何测量的?</think>在WebRTC中,REMB(Receiver Estimated Maximum Bitrate)算法**不直接使用丢包率计算带宽**,而是主要依赖**延迟梯度**进行带宽估计。以下是关键分析: ### 1. REMB的核心机制 - **延迟梯度分析**:REMB接收端通过计算连续数据包的到达时间间隔变化($\Delta t$),检测网络拥塞。数学表示为: $$ \text{延迟梯度} = \frac{\Delta \text{到达时间}}{\Delta \text{发送时间}} $$ 当该值持续增大时,表明网络排队延迟增加,触发带宽下调[^1]。 - **丢包率的辅助作用**:虽然REMB自身不依赖丢包率,但发送端会**综合REMB建议值和丢包率**调整最终发送码率: ```mermaid graph LR A[REMB接收端] -->|带宽估计| B[基于延迟梯度] C[发送端] -->|最终码率| D[REMB建议值] C -->|最终码率| E[丢包率阈值] ``` ### 2. 丢包率的独立作用 - **基于丢包的拥塞控制**:WebRTC发送端独立监测丢包率: - 丢包率 < 2%:缓慢增加码率 - 丢包率 > 10%:乘性降低码率(公式:$ \text{new\_rate} = \text{current\_rate} \times (1 - 0.5 \times \text{loss\_ratio}) $)[^2] - **REMB的协同**:REMB提供带宽上限,丢包率提供即时拥塞反馈,两者共同约束发送码率。 ### 3. 性能对比 | 指标 | REMB(延迟驱动) | 丢包率驱动 | |--------------|------------------|------------------| | 响应速度 | 毫秒级 | 秒级(需统计窗口)| | 抗随机丢包 | 强 | 弱 | | 网络适应性 | 高(动态调整) | 中(固定阈值) | ### 4. 实际应用建议 若需结合丢包率优化REMB: 1. 在发送端实现**双因子决策**: ```python def adjust_bitrate(remb_bw, loss_rate): if loss_rate > 0.1: # 丢包率>10% return min(remb_bw, current_rate * 0.8) return remb_bw ``` 2. 使用**平滑函数**避免震荡: $$ \text{final\_rate} = \alpha \times \text{remb\_rate} + (1-\alpha) \times \text{loss\_adjusted\_rate} \quad (\alpha=0.7) $$ > ⚠️ 注意:过度依赖丢包率可能导致**带宽低估**(尤其在无线网络),REMB的延迟分析仍是WebRTC的默认推荐方案[^3]。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值