在WebRTC中有多种控制算法，可以被分为四个类别，拥塞控制(BandWidth Estimation,BWE)。音频处理：Acoustic Echo Cancellation,AEC; Noise Supression(NS); AutoMatic Gain Control(AGC)。抖动与抗丢包控制：NetEQ(以JB为核心的音频处理);视频JB（使用卡尔曼滤波以及直方图检测）;Forward Error Correction(FEC)。Pacing。而本文想要谈论的是GCC(Google congest control)

对于GCC（仅针对GCC V2& TransportCC）主要作用在发送端，用于预测网络带宽瓶颈 ACK码率，控制编码器码率，和Pacing配合控制发包频率。主要分成2中方式：Delay-based Controller(核心算法：基于贝叶斯或者趋势滤波); Loss-based Controller，以下是delay_based的基本流程

1
2
3
4
5
6
7
8

Sender：给每个包打上 TransportSequenceNumber，记录发送时间 $T$。
Receiver：记录到达时间 $t$，通过 TCC Feedback 批量发回 Sender。
Sender (BitrateEstimator)：计算 ACK 码率，作为“保底”。
Sender (Trendline)：计算 $d_i$（单向延迟增量）。累加 $d_i$ 得到 $AccumulatedDelay$。对累积延迟做线性回归，算出斜率 $Slope$。
Sender (Detector)：对比 $Slope$ 和自适应阈值 $\gamma$。输出信号：Overuse / Normal / Underuse。
Sender (Controller)：Overuse -> 乘法减速（基于 Acked Bitrate）。Normal -> 加法/乘法增速。
Pacer：最终根据算出的 Target Bitrate 平滑发包。

TCC-贝叶斯方法

在接收端部分，具备这样的一个类，通过记录包到达时间，生成 Transport-CC Feedback 报文，发回给发送端。发送端同样具备这样一个类，

TCC-Trendline

Loss-based Controller

前面已经有两种方法用于拥塞评估，分别是bayes和TrendLine，都是基于延时的。

还有一种基于丢包的，实际上就是通过设置丢包门限来评定此时的网络传输质量。

1. <2%,网络质量很好，可以加大码率
2. 2%<x<10%,说明网络与发送速率匹配
3. 10%<,需要降低码率至（1-0.5*丢包率）*当前码率