在GCC（Google Congestion Control）拥塞控制算法中，包含了两种带宽估计算法，分别是基于延迟的带宽估计算法和基于丢包的带宽估计算法。
其中，基于延迟的带宽估计算法有新旧两个不同的实现版本，分别是：旧版使用基于接收端的Kalman滤波器带宽估计算法，新版使用基于发送端的Trendline滤波器带宽估计算法。
在WebRTC中，为了向前兼容仍保留了旧版的实现，且对于视频流会同时开启两种基于延迟的带宽估计算法。因此，如果存在视频流时，GCC还好收到从接收端返回的带宽估计值：REMB（Remote Estimated Maximum Bitrate）。GCC算法最终会选取这三个带宽估计值中的最小值作为当前的带宽估计值。
本文介绍的是新版基于延迟的带宽估计算法中的Trendline滤波器，可根据数据包的延迟梯度的变化预测带宽的变化趋势，以此为参考对当前码率进行相应的调整，进而获得更为接近真实情况的带宽估计值。
所谓关键帧，就是不需要参考其他视频帧，可单独解码的帧。比如H264中的I帧。在WebRTC中有两种关键帧请求方式，分别是：
二者的主要区别在于报文结构和使用场景不同，但实际上在发送端处理两种请求的逻辑很可能是一样的，比如，WebRTC中的实现就是如此。
在WebRTC中，使用的GCC（Google Congestion Control）作为拥塞控制算法，且该算法有新旧两个版本。二者的主要区别之一就是基于延迟的带宽估计算法的实现不同：旧版采用的是基于接收端的Kalman滤波器带宽评估算法，而新版则是基于发送端的Trendline滤波器带宽评估算法。
此前在 WebRTC之抖动估计 中简单介绍过关于时延的概念，简单说就是指一个数据包或信号从发送端抵达接收端所需的时长。由于网络拥塞等原因，即便是以均匀时间间隔连续发送的数据包，在抵达接收端时的时间间隔也很可能是不均匀的。
新版采用的Trendline滤波器算法，是一种基于包的时延梯度的变化来评估当前网络变化趋势的算法，而时延梯度的计算基于发送时间间隔（inter-departure）和抵达时间间隔（inter-arrival）。
关于Trendline滤波器带宽评估算法的具体实现留待后续，本文介绍的是关于包组时间间隔的计算方式。
RTT（round-trip time），往返时延，表示在通信过程中，发送端发送的数据包或信号抵达接收端后，再返回发送端的整个往返过程所需时长。
RTT由三个部分决定，分别是
由于接收端的处理时长只与接收端的处理逻辑相关，不涉及网络传输，所以在RTT计算过程中一般不包括接收端的处理时长。即：
1 | RTT = 链路的传输时长 + 路由器的排队和处理时长 |
其中，路由器的排队和处理时长会随着整个网络的拥塞程度的变化而变化。
简言之，网络拥塞程度越严重，RTT的值也就越大。因此，RTT的变化在一定程度上反应了整个网络的拥塞程度的变化。这也是RTT常被当做重要指标用于分析网络性能的原因。
时延和抖动是两个不同但又相互关联的概念。时延是网络通信中的一个重要指标，用于衡量数据包从一个端点传送到另外一个端点所需的时间。
在网络通信中，连续发送的数据包即便使用相同的路径也会产生不同的时延。原因在于，路由器一次只能处理一个数据包。当数据包抵达的速度大于路由器处理数据包的速度，会被暂时放入路由器的网络缓冲区，等待路由器的处理和转发，从而增加了数据包的传输时延。
抖动就是用于表示数据包之间传输时延的不一致性，即用来衡量数据包传输时延的变化程度。
导致抖动产生的原因有很多，比如网路拥塞，网路错误，丢包等。