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

最新推荐文章于 2024-05-30 00:15:00 发布

原创

最新推荐文章于 2024-05-30 00:15:00 发布 · 647 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#音视频

文章介绍了WebRTC中TrendLine滤波器与Goog-REMB在拥塞控制上的差异，TrendLine滤波器使用发送端评估和控制码率，而Goog-REMB依赖接收端的反馈。此外，文章详细解释了TrendLine滤波器的工作原理，通过最小二乘法计算斜率来预测网络状态，并调整码流大小。

与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