webrtc中基于时延的拥塞控制TCC

Posted 2023-05-09

参考技术A 其二：

实践： 先定为400ms, 基于多次实验测试数据调节。

根据反馈的recv delta计算delay(同rtcp jitter):

然将delay做累加和平滑：

smoothingCoef是个经验值， 在webrtc trendline_estimator.cc中取0.9。

另外还有一个recvTime = recvTime(i) - firstRecvTime;
接着将recvTime, accumulatedDelay和smoothedDelay保存到一个固定窗口大小的队列HistoryQueue中，

然后按以下公式计算线性斜率：

得到的slope即是我们需要的带宽变化趋势。

为了限制slope不让它跑偏了，
在HistoryQueue中取前80%的包中最小的accumlatedDelay(k), 以及这个包对应的recvTime(k),
在HistoryQueue中取后80%的包中最大的accumlatedDelay(m), 以及这个包对应的recvTime(k)

slope不能大于slope(max)。

基于slope判断出网络带宽的使用状态： overuse, underuse, normal。

最后，基于新的网络带宽状态， 通过AIMD调整带宽。

webrtc拥塞控制

webrtc两种拥塞控制策略

1、基于延迟（delay-based）的拥塞控制

该算法由数据的接收方实现，接收方需要记录每个数据包到达的时间和大小，并计算每个数据分组之间（inter-group）的延迟的变化，由此判断当前网络的拥塞情况，并最终输出码率估计值由RTCP feedback（TMMBR或 REMB）反馈给发送方；

2、基于丢包（loss-based）的拥塞控制

该算法则由数据的发送方来实现，发送方通过从接收方周期性发来的RTCP RR（Receiver Report）中获取丢包信息以及计算RTT，并结合TMMBR或REMB中携带的码率信息算得最终的码率值，然后由媒体引擎根据码率来配置编码器，从而实现码率的自适应调整。

webrtc的拥塞控制算法

WebRTC包含三种拥塞控制算法，GCC、BBR和PCC。其中，BBR一开始是针对TCP的拥塞控制提出来的。它的输入为ACK/SACK，输出为拥塞窗口(congestion_window)发送速度(pacing_rate)。

影响视频会议质量的因素主要在于视频图像质量和传输时延.
待续。。。