找回密码
 立即注册
LiveVideoStack 首页 资讯 查看内容
  • QQ空间
  • 回复
  • 收藏

WebRTC的拥塞控制和带宽策略(1)

2018-5-24 08:00

网络的波动带来的卡顿直接影响着用户的体验,在WebRTC中设计了一套基于延迟和丢包反馈的拥塞机制(GCC)和带宽调节策略来保证延迟、质量和网路速度之间平衡,本文中重点是介绍基于trendline滤波的评估模型。本文来自学霸君资深架构师袁荣喜和萍乡学院辛锋的投稿,并由LiveVideoStack全文发布。


文 / 袁荣喜,辛锋


在视频通信的技术领域WebRTC已成为主流的技术标准,WebRTC包涵了诸多优秀的技术,譬如:音频数字信号处理技术(AEC, NS, AGC)、编解码技术、实时传输技术、P2P技术等,这些技术目的都是为了实现更好实时音视频方案。但是在高分辨率视频通信过程中,通信时延、图像质量下降和丢包卡顿是经常发生的事,甚至在WiFi环境下,一次视频重发的网络风暴可以引起WiFi网络间歇性中断,通信延迟和图像质量之间存在的排斥关系是实时视频过程中的主要矛盾。


分析WebRTC是如何解决这个矛盾之前,先来看看我们在在线教育互动的生产环境统计到的视频延迟和人感官的关系,大致如下:

0 ~ 400毫秒

人感觉不到视频在通信过程中的延迟

400 ~ 800毫秒

人能感觉到轻微延迟,但不影响通信互动

800毫秒以上

人能感觉到延迟而且影响通信互动


也就是说,通信过程中最好将视频延迟控制在800毫秒以内。除了延迟,视频图像质量也是个对人感官产生差异的关键因素,我们以640x480分辨率每秒24帧的H264编码情况下视频码率和人感官之间的关系(这组数据是我们通过小范围线上用户投票打分的数据)


800kbps以上

人对视频清晰度满意,感觉不到视频图像中的信息丢失

480 ~ 800kbps

人对视频清晰度基本满意,有时能感觉到视频图像中的信息丢失

480kbps以下

人对视频清晰度不满意,大部分时候无法辨认图像中的细节信息


从上面的描述可以知道视频质量保持在一个可让人接受的质量范围是需要比较大的带宽码率支持的,如果加上控制延迟,则更需要网络有很好速度和稳定性。但是很不幸,我们现阶段的移动网络和家用WiFi并不是我们想象中的那么好,很难做到在实时视频通信中一个让人非常满意的程度。为了解决以上几个问题,WebRTC设计了一套基于延迟和丢包反馈的拥塞机制(GCC)和带宽调节策略来保证延迟、质量和网路速度之间平衡,这是一个持续循环过程,如下图:


图1:拥塞控制循环示意图


1) estimator通过RTCP的feedback反馈过来的包到达延迟增量和丢包率信息计算出网络拥塞状态并评估出适合当前网络传输的码率,根据这个码率改变视频编码器码率,然后改变pacer的码率

2) pacer会根据这个码率改变pacer的网络发送速度和padding比例,并用新的网络发送速度来定时触发发包事件。

3) sender收到pacer的发送事件,进行RTP报文发送。

4) receiver接收到RTP报文,进行arrival time统计和丢包统计

5) feedback定时对receiver统计的信息进行RTCP编码,并反馈到发送端的estimator进行新一轮的码率评估。


以上是整个WebRTC拥塞控制和带宽调节过程,下面这个示意图是这个过程涉及到WebRTC内部模块关系。


图2:WebRTC的拥塞控制模块关系图


需要说明的是红框中基于接收端的kalman filter带宽评估模型已经在新版本的WebRTC中不采用了,只做了向前版本兼容,新版本的WebRTC都是采用发送端的trendline滤波器来做延迟带宽评估,本文中重点是介绍基于trendline滤波的评估模型,下面依次来分析WebRTC的这五个过程。


1 estimator


estimator的功能就是通过接收端反馈过来的包到达时刻信息、丢包信息和REMB信息进行当前网络状态的码率评估,WebRTC拥塞控制有两部分:基于延迟的拥塞控制和基于丢包的拥塞控制,它是一个尽力而为的拥塞控制算法,牺牲了拥塞控制的公平性换取尽量大的吞吐量。从设计结构来描述向它输入延迟和丢包信息,它就会输出一个适应当前网络状态的码率值。示意图如下:


图3:WebRTC的CC estimator输入与输出


从上图可以看出,estimator基于延迟的拥塞控制是通过trendline滤波再进行过载判断,最后根据过载情况进行aimd码率调控评估出一个bwe bitrate码率,这个码率会合丢包评估出来的码率和remb来决定最后的码率。


1.1 基于延迟的拥塞控制


基于延迟的拥塞控制是通过每组包的到达时间的延迟差(delta delay)的增长趋势来判断网络是否过载,如果过载进行码率下调,如果处于平衡范围维持当前码率,如果是网络承载不饱满进行码率上调。这里有几个关键技术:包组延迟评估、滤波器趋势判断、过载检测和码率调节。


1.1.1 包组与延迟


WebRTC在评估延迟差的时候不是对每个包进行估算,而是采用了包组间进行延迟评估,这符合视频传输(视频帧是需要切分成多个UDP包)的特点,也减少了频繁计算带来的误差。那么什么是包组呢?就是距包组中第一个包的发送时刻t0小于5毫秒发送的所有的包成为一组,第一个超过5毫秒的包作为下一个包组第一个包。为了更好的说明包组和延迟间的关系,先来看示意图:


图4:包组与延迟示意图


上图中有两个包组G1和G2, 其中第100号包与103号包的时间差小于5毫秒,那么100 ~ 103被划作一个包组。104与100之间时间超过5毫秒,那么104就是G2的第一个包,它与105、106、107划作一个包组。知道了包组的概念,那么我们怎么通过包组的延迟信息得到滤波器要的评估参数呢?滤波器需要的三个参数:发送时刻差值(delta_timestamp)、到达时刻差值(delta_arrival)和包组数据大小差值(delta_size)。从上图可以得出:



1.1.2 滤波器


我们通过包组信息计算到了delta_timestamp、delta_arrival和delta_size,那么下一步就是进行数据滤波来评估延迟增长趋势。在WebRTC实现了两种滤波器来进行延迟增长趋势的评估,分别是:kalman filter和trendline filter, 从图2中我们知道kalman filter是运行在接收端的,我在这里以不做介绍,有兴趣的可以参考https://www.jianshu.com/p/bb34995c549a。

这里介绍trendline filter,我们知道如果平稳网速下传输数据的延迟时间就是数据大小除以速度,如果这数据块很大,超过恒定网速下延迟上限,这意味着要它要占用其他后续数据块的传输时间,那么如此往复,网络就产生了延迟和拥塞。Trendline filter通过到达时间差、发送时间差和数据大小来得到一个趋势增长值,如果这个值越大说明网络延迟越来越严重,如果这个值越小,说明延迟逐步下降。以下是计算这个值的过程。


先计算单个包组传输增长的延迟,可以记作:



然后做每个包组的叠加延迟,可以记作:



在通过累积延迟计算一个均衡平滑延迟值,alpha=0.9可以记作:

然后统一对累计延迟和均衡平滑延迟再求平均,分别记作:

我们将第i个包组的传输持续时间记作:

趋势斜率分子值为:


趋势斜率分母值为:


最终的趋势值为:

原作者: 袁荣喜 辛锋 来自: LiveVideoStack
文章点评
相关文章