介绍

Sender Side Bandwidth Estimation 发送方带宽预估。Sender Side BWE 是新方案，利用的是 RTCP 中的 TransportCC 协议。

Receiver Estimated Maximum Bitrate 接收端预估最大码率。REMB 是旧方案，利用的是 RTCP 中的 REMB 协议。

背景

WebRTC 中的拥塞控制算法有三种：GCC、BBR、PCC。GCC 是 WebRTC 的默认算法，GCC 包含基于 丢包 和 延迟 两种情况的算法。以下所有内容都是 GCC 中的。

拥塞控制的源码在：目录 src/modules/congestion_controller/ 下

GCC 全称 Google Congestion Control。

GCC 由于新旧版本兼容原因 有三种 实现的方式。

1. 根据 丢包 情况计算带宽。
2. 根据 延迟 情况在 接收端 计算带宽。旧方案，使用卡尔曼滤波器。
3. 根据 延迟 情况在 发送端 计算带宽。新方案，使用最小二乘法作线性回归。

为什么要切换方案

也就是新的比旧的好在哪？

Google 给的官方解释是：> https://groups.google.com/g/discuss-webrtc/c/ZyKcu3E9XgA/m/hF0saddeLgAJ

1. 所有决策逻辑都在一端们会让测试新算法变得简单。
2. 发送端知道自己发送的数据流是什么类型，可以在发送普通视频和做屏幕广播时选择不同的算法。

当然更实际的好处是：新的方案在应对峰值流量的能力上比旧的好。

基于 丢包 的拥塞控制

基本思想：丢包率小，提高码率；丢包率大，降低码率；丢包率适中，不进行调整。

$A_s(t_k)=\{\begin{array}{ll}{A}_s(t_{k-1})(1-0.5f_l(t_k))& f_l(t_k)>0.1\\ 1.05(A_s(t_{k-1}))& f_l(t_k)<0.02\\ A_s(t_{k-1})& otherwise\end{array}$

$A_s(t_k)$ 即为 $t_k$ 时刻的带宽估计值，$f_l(t_k)$ 即为 $t_k$ 时刻的丢包率。

基于 延迟 的拥塞控制

最小二乘法求线性回归方程

基本思想：以时间为x轴，延迟梯度为y轴。对其中的点做一元线性拟合求斜率。斜率越大说明网络越拥塞。

一元线性方程：$y=ax+b$

求线性回归方程系数a：$a=\frac{{\sum }_{i=1}^n(x_i-\bar{x})(y_i-\bar{y})}{{\sum }_{i=1}^n(x_i-\bar{x}{)}^2}$

关键技术

InterArrival 到达间隔

一帧视频往往是由多个 RTP 包发送的，所以首先将 RTP 的数据按照 5ms 分组，之后对相邻的两组数据包进行计算。

5ms 是 GCC 草案中提出的：The Pacer sends a group of packets to the network every burst_time interval. RECOMMENDED value for burst_time is 5 ms.

理论上，WebRTC 是按照包组为单位进行计算的。但为理解的方便，后面将包组统一理解为一个数据包。

计算内容包括：

1. 发送时刻差：$△timestamp=T_2-T_1$
2. 接收时刻差：$△arrival=t_2-t_1$
3. 数据包大小差：$△size=G_2-G_1$ 虽然很多博文里都提到计算数据包大小差，但实际后面都没有用到。

TrendlineEstimator 趋势线预估

通过上述的三个值，可以计算：

一个包的延迟：$dela{y}_i=△arrival-△timestamp$

每个包累计的延迟：$ac{c}_{dela{y}_i}=\sum dela{y}_0+dela{y}_1+...+dela{y}_i$

WebRTC 中对累计的延迟做了平滑处理，也就是取了之前的累计延迟的 90%，取了当前包累计延迟的 10% ，从而减少了变化幅度。$sm{o}_{dela{y}_i}=\alpha \ast sm{o}_{dela{y}_{i-1}}+(1-\alpha )\ast ac{c}_{dela{y}_i}$ 这里 $\alpha =0.9$

现在有了平滑后的延迟梯度，有了每个包的到达时间。那么时间为 x 轴，延迟梯度为 y 轴。

• 如果随着时间的变化 延迟梯度增加，也就是 $y=ax+b$ 这条线的斜率 $a>0$，说明网络情况差。
• 如果随着时间的变化 延迟梯度保持不变，也就是 $y=ax+b$ 这条线的斜率 $a=0$，说明网络稳定。
• 如果随着时间的变化 延迟梯度减小，也就是 $y=ax+b$ 这条线的斜率 $a<0$，说明网络情况在好转。

WebRTC 中使用最小二乘算法计算出了 $a$ 的值。具体计算过程，并不建议深入阅读，可能会把自己绕进去。

阿里云(WebRTC 拥塞控制 | Trendline 滤波器) 个人觉得算法这部分将的比别的好 https://developer.aliyun.com/article/781509

剩余的公式如下，最好别看：

剩余计算公式：

对 包的累计延迟 和 包的平滑延迟 求平均：

$x_i=\frac{\sum dela{y}_0+dela{y}_1+...+dela{y}_i}{i}$ $y_i=\frac{\sum sm{o}_{dela{y}_0}+sm{o}_{dela{y}_1}+...+sm{o}_{dela{y}_i}}{i}$

每个包组的传输时间为：$tran{s}_i=t_i-first\_arriva{l}_i$

趋势斜率分子：$numerato{r}_i=\sum _{k=0}^i(tran{s}_k-x_k)\ast (sm{o}_{dela{y}_k}-y_k)$

趋势斜率分母：$denoinato{r}_i=\sum _{k=0}^i(tran{s}_k-x_k{)}^2$

趋势斜率为：$trendlin{e}_i=\frac{numerato{r}_i}{denoinato{r}_i}$

Overuse Detector 过载检测器

上述步骤已经计算出斜率 $a$ ，过载检测器就会利用 $a$ 与 阈值 $\gamma$ 进行比较，从而决策当前网络所处状态。

由于实际计算出的 $a$ 非常小，所以 WebRTC 对其进行了放大，会用 $a\ast 包组数量\ast 增益系数$ 。

而 阈值 也是需要动态计算的，阈值计算公式：${\gamma }_i={\gamma }_{i-1}+\Delta t_i\ast k_i\ast (|m_i|-{\gamma }_{i-1})$

$\Delta t_i$ 表示 距离上一次更新阈值的时间。$k_i$ 表示 一个系数。$m_i$ 表示 上面说的被放大后的 $a$ 。

$k_i$ 的取值规则如下：$k_i=\{\begin{array}{ll}{k}_d=0.039& |m_i|<{\gamma }_{i-1}\\ k_u=0.0087& otherwise\end{array}$ $k_d$ 与 $k_u$ 分别决定阈值增加以及减小的速度。

WebRTC 将当前网络所处状态分为三个。

• overuse：$m(ti)>\gamma (ti)$ 并且持续时间超过 100ms
• underuse：$m(ti)<-\gamma (ti)$ 并且持续时间超过 100ms
• normal：$-\gamma (ti)<m(ti)<\gamma (ti)$

AIMD Rate Controller 码率控制器

AIMD 的全称是 Additive Increase Multiplicative Decrease，意思是：和式增加，积式减少。直白点就是：增加的时候用加法，减少的时候用乘法。增加的时候慢一点，降低的时候快一点。

但是，AIMD 是 TCP 底层的码率调节概念，WebRTC 没有完全照搬，而是有自己一套算法。

该模块同样也维护了一个状态机：码流控制状态机。

保存当前码流改变的状态：Decrease 正在降低码率，Hold 正在保持码率，Increase 正在增加码率。

计算出当前网络状态后，根据码流控制器状态机，按照 和式增加，积式减少 的原则，估算出下一时刻发送端应该发送码流的大小。

$A_r(t_i)=\{\begin{array}{ll}\alpha A_r(t_{i-1})& \alpha =1.08\sigma =Increase\\ \beta R_r(t_i)& \beta =0.85\sigma =Decrease\\ A_r(t_{i-1})& \sigma =Hold\end{array}$

当前是 Increase 状态，如果吞吐量 $R_r$ 和 链路容量（历史吞吐量的指数平滑）相差较大，则对当前码率（上次更新的码率）使用乘性增加；如果相差较小，则使用加性增加。

当前是 Decrease 状态，直接将当前吞吐量 $R_r$ * 0.85 作为新码率，如果该码率可能仍大于上一个调整后的码率，则使用链路容量 $R_r$ * 0.85 作为新码率。

据此，得到基于延时预估出来的码率。