webrtc 带宽估计

原创

已于 2022-02-07 09:07:55 修改 · 3.4k 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#webrtc #p2p #linq

于 2022-02-06 14:56:13 首次发布

本文详细解读了WebRTC中的带宽估计与码率控制算法，涉及延时梯度、卡尔曼滤波、Trendline滤波、丢包率计算、动态阈值调整及Aimd Rate Control。核心内容包括延时趋势判断、网络状态识别与码率调整策略。

1、整体架构：

         此图是接收端码率控制整体结构图分成3个部分。
        第一部分采集和发送：camera encode通过Pacer并结合fec发送。
        第二部分基于延时的码率计算（卡尔曼模型）。
        第三部分是结合丢包和延时计算出综合码率发送编码器。

notes:发送端带宽估计是一种算法。
算法通过5步评估出基于延时的码率.1->2->3->4&5。

        到达时间模型：计算包组延时。
        到达时间滤波器:trendline即y=bx+a;x,y带入公式,计算斜率b,就是延时趋势.通过延时趋势计算延时。
        过载检测器:通过延时趋势trendline即协议b与门限比较,获得当前网络状态overuse,underuse, or normal。
        自适应阀值（门限）:阀值也是每次更新。
        速率控制：根据过载检测器计算的网络状态结合当前码率状态，根据上面的流程图，获取新的码率状态并计算新的码率(不变,加,乘,减)。
        transport-cc是接收端发送给发送端的recv ts，是该算法的输入。
        卡尔曼滤波和trendline滤波类似，只是将第二步trendline滤波改成了卡尔曼滤波。

2 发送端基于丢包率的码率控制

接收端维护两个计数器，每收到一个RTP包都更新：

transmitted，接收到的RTP包的总数；
retransmitted，接收到重传RTP包的数量；

某时刻收到的有序包的数量Count = transmitted-retransmitte,当前时刻为Count2,上一时刻为Count1;

接收端以一定的频率发送RTCP包（RR、REMB、NACK等）时，会统计两次发送间隔之间(fraction)的接收包信息。

接收端发送的RR包中包含两个丢包:

一个是fraction_lost，是两次统计间隔间的丢包率(以256为基数换算成8bit)。

一个是cumulative number of packets lost，是总的累积丢包。

2.1 丢包的计算方法：

1) 两次发送间隔之间理论上应该收到的包数量=当前收到的最大包序号-上个时刻最大有序包序号。

2) 两次发送间隔之间实际接收到有序包的数量=当前时刻收到的有序包的数量-上一个时刻收到的有序包的数量 uint32_t rec_since_last = Count2 - Count1。

3) 丢包数=理论上应收的包数-实际收到的包数。

4）int32_t missing = exp_since_last - rec_since_last，missing即为两次发送间隔之间的丢包数量，会累加并通过RR包通知发送端。

2.2 基于丢包的码率评估

基于丢包的拥塞控制比较简单，其基本思想是根据丢包的多少来判断网络的拥塞程度.
丢包越多则认为网络越拥塞，那么我们就要降低发送速率来缓解网络拥塞；
如果没有丢包,这说明网络状况很好,这时候就可以提高发送码率，向上探测是否有更多的带宽可用.
实现该算法有两点：一是获得接收端的丢包率，一是确定降低码率和提升码率的阈值。

发送端收到RTCP RR报文并接收丢包率后，根据公式计算发送端码率：当丢包率大于0.1时，说明网络发生拥塞，此时降低发送端码率，当丢包率小于0.02时，说明网络状况良好，此时增大发送端码率，其他情况下，发送端码率保持不变。