【音视频第13天】另外一种拥塞控制算法-TransportCC

与Goog-REMB区别

与Goog-REMB有两个区别：
将拥塞评估算法从接收端移动到了发送端，评估和控制是一体的。TransportCC是发送端评估发送端接着改变码率，REMB是接收端评估，把评估出来的值给发送端，然后发送端再控制码率发送。
滤波器从卡尔曼滤波器变成了TrendLine滤波器来进行拥塞评估。

TrendLine滤波器

卡尔曼滤波器：基本思想是通过已有的观测数据，总能找到⼀条线，使得所有观测数据到这条线的误差（距离）的平⽅和最⼩，⽽这条线就是Trendline要求得的值。从（0，0）点出发，⼀定有⼀条直线y=k·x+b，使得从测量值到该直线的误差的平⽅和最⼩，如图10.6所⽰。这条直线的斜率就是数据⾛向的趋势，有时候它是上扬的，有时候它是下降的。WebRTC发送端拥塞评估算法正是利⽤这个趋势来评估下⼀个时刻的⽹络拥塞状态的，如果斜率向上，说明线路拥塞，如果斜率向下，说明拥塞缓解。

WebRTC可以获得每个包组接收与发送的时延差，即di。每隔⼀段时间（⼀个窗⼝期）就计算⼀下这段时间内所有的di值，然后通过最⼩
⼆乘法求出直线的斜率，再根据这条直线的斜率评估出下⼀时刻的⽹络状态和码流⼤⼩。

在上述公式中，di表⽰当前包组到达时⻓与包组发送时⻓之差。正常情况下该值有正有负，即当⽹络状况不好时该值不断增⻓，⽽⽹络
状况变好时该值不断下降，所以⻓时间看di的累加值应该趋于0。WebRTC将累计的di作为yi值，同时考虑到某个时刻包组可能出现较⼤
的抖动，为了使yi更平滑，真正的yi由式（10.19）得出。其中，α=0.9。xi的计算⾮常简单，如式（10.20）所⽰。它是当前包组最后⼀个包的接收时间与传输开始时第⼀个包的接收时间之差。你可能会觉得这个值⾮常⼤，不过没关系，因为后⾯的计算⽤的都是相对值。

有了xi和yi之后，就可以求它们的平均值了。这⾥需要注意的是，WebRTC中是按窗⼝求平均值的，默认窗⼝⼤⼩n=20（窗⼝⼤⼩是可以动态变化的）。求x、y平均值的公式如下：

有了x，y以及它们在窗⼝内的平均值 和 后，就可以通过它们找到⼀条误差平⽅和最⼩的直线，并求出它的斜率，公式如下：

实际上，这⾥求出的ki值与接收端延时拥塞控制算法中的mi值表达的是同⼀个含义，即在这个窗⼝期内发送队列的增⻓梯度。因此，
像过载状态检测、⽬标码流的控制等都可以延⽤之前的算法，⽽WebRTC也正是这样做的。