产品角度看数据
下图是Google Stadia 针对4K保持60Fps情况下的带宽估计。
和我们QL之前的4K数据测试是一致的。 4K的带宽占用在10~35Mb区间内
延时表现
从源代码角度分析
更多技术资讯下载: 2img.ai
相关配图由微信小程序【字形绘梦】免费生成
WebRTC的拥塞控制算法，WebRTC的传输层是基于UDP协议，在此之上，使用的是标准的RTP/RTCP协议封装媒体流。RTP/RTCP本身提供很多机制来保证传输的可靠性，比如RR/SR, NACK，PLI，FIR, FEC，REMB等，同时WebRTC还扩展了RTP/RTCP协议，来提供一些额外的保障，比如Transport-CCFeedback, RTP Transport-wide-cc extension，RTP abs-sendtime extension等，其中一些后文会详细介绍。
GCC算法主要分成两个部分，一个是基于丢包的拥塞控制，一个是基于延迟的拥塞控制。
在早期的实现当中，这两个拥塞控制算法分别是在发送端和接收端实现的，接收端的拥塞控制算法所计算出的估计带宽，会通过RTCP的remb反馈到发送端，发送端综合两个控制算法的结果得到一个最终的发送码率，并以此码率发送数据包。下图便是展现的该种实现方式：
从图中可以看到，Loss-Based Controller在发送端负责基于丢包的拥塞控制，它的输入比较简单，只需要根据从接收端反馈的丢包率，就可以做带宽估算；上图右侧比较复杂，做的是基于延迟的带宽估计，这也是本文后面主要介绍的部分。在最近的WebRTC实现中，GCC把它的两种拥塞控制算法都移到了发送端来实现，但是两种算法本身并没有改变，只是在发送端需要计算延迟，因而需要一些额外的feedback信息，为此WebRTC扩展了RTCP协议，其中最主要的是增加了Transport-CC Feedback，该包携带了接收端接收到的每个媒体包的到达时间。
基于延迟的拥塞控制比较复杂，WebRTC使用延迟梯度来判断网络的拥塞程度，延迟梯段的概念后文会详细介绍；
其算法分为几个部分：
l 到达时间滤波器
l 过载检测器
l 速率控制器
在获得两个拥塞控制算法分别结算到的发送码率之后，GCC最终的发送码率取的是两种算法的最小值。下面我们详细介绍WebRTC的拥塞控制算法GCC。
Paragoger衍生者AI训练营。发布者：稻草人，转载请注明出处：https://www.shxcj.com/archives/6660
