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

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

2018-5-24 08:00

3.1 RTP扩展


WebRTC为了配合接收端进行延迟包序列和丢包统计做了下列扩展:


transport sequence传输通道的只增sequence,每次发送报文时自增长,配合接收端统计丢包、通过反馈这个sequence可以计算得到发包的时刻。


TransmissionOffset 发送报文的相对时刻,这个相对时刻值t是发送报文的绝对时刻T1和视频帧时间戳T0差值。早期的WebRTC是在接收端进行estimate bitrate,所以过载判断是在接收端完成的,这个值就是为了kalman filter计算发包造成的延迟用的,新版本还携带这个值以便低版本的WebRTC能兼容。


3.2  packet cache


packet cache是一个key/value结构的包缓冲池,视频帧在进行RTP分片打包后不会立即发送出去,而是要等待pacer的发送信号进行发送。所以打包后会按[id,packet]键值对插入到packet cache中。一般packet cache会保存600个分片报文,最大9600个,插入新的会将最旧的报文删除,packet cache这样做的目的除了配合pacer发送外,也为了后面响应nack的丢包重传。


3.3 NACK与丢包重传



图7:RTP NACK过程的示意图


WebRTC在评估到收发端之间RTT延迟比较小的时候会采用NACK来进行丢包补偿,NACK是一个请求重发过程,其流程如上图所示。这个过程有一个问题是在网络抖动和丢包很厉害的情况下有可能造成同一时刻收到很多NACK的重传请求,发送端瞬间把这些重传请求放入pacer中进行重发,这样pacer的延迟会增大,而且pace的参考码率会随着pace queue的延迟控制变的很大而出现间歇性网络风暴。WebRTC在处理NACK重传时设计了一个重传码率控制器,其设计原理是通过统计单位时间窗口周期中发送的字节数据来限流,如果这个时间窗内发送的数据的码率大于estimator评估的码率,不进行当前NACK请求的重传,等待下一个NACK。


3.4 FEC与码率分配


WebRTC应对丢包时除了NACK方式,在收发端之间RTT很大时候会开启FEC来进行丢包补偿,我们在这里不介绍FEC具体算法,只介绍FEC的码率分配策略。从整个通信机制我们很容易得出这样一个共识:



FEC bitrate到底应该设置多大呢?它先根据feedback中反馈过来的丢包率(loss fraction)来确定使用哪一种FEC,在根据每中FEC和丢包率来确定FEC使用的码率,但需要满足一下条件:



feedback的码率被设定为target bitrate的5%,WebRTC是通过控制feekback的频率来进行调控分配的。padding bitrate是通过pacer queue和budget来控制的。Target bitrate减去这些码率之和就是给视频编码器的码率。每次estimator评估出来码率后,会先进行这些计算得到最后的video bitrate,并将这个值作为编码器的编码码率,以此来达到防止拥塞的目的。


4 receiver


receiver模块的工作相对来说比较简单,它就做三件事情:记录每个报文的到达时刻(arrival timestamp)、丢包率(lost fraction)和receiver bitrate。早期的WebRTC提供了图2红框当中kalman filter评估码率的评估器,因为kalman filter怕抖动特性且需要借助remb心跳进行反馈,remb的反馈周期是1秒,在收发端网络间歇性断开或者大抖动下,容易失效,所以WebRTC采用了在发送端进行估算,整个逻辑也更加简便。


4.1 报文到达时间


图8:到达报文统计图


上图是一个统计RTP报文到达时刻的序列图,图中的seq是RTP扩展中的transport sequence,接收端用一个k/v([seq,arrival timestamp])键值对数据结构来保存最近500毫秒未反馈的到达时刻信息,通过时间窗口周期来进行淘汰老的到达时刻记录。


4.2 丢包率计算


丢包率计算过程是这样的,我们把上次统计丢包率时刻的最大sequence记着prev_seq, 把当前收到的最大sequence记着cur_seq,当前统计丢失的报文记着count,WebRTC在RTCP中描述丢包率采用的是uint8,为了保证精确度将256记着100%的丢包率,那么很容易得:



这里需要提的是WebRTC在统计报文是否丢失是通过sequence的连续性和网络的jitter时间来确定的,只有落在jitter抖动范围之外的丢包才是算是作丢包。


4.3 接收码率统计


接收端码率统计采用的是最近单位时间窗(1000毫秒)周期内收到的的字节数来计算,WebRTC设计了一个1毫秒为最小单位的窗口数组来进行统计,每个最小单位是数字,这个数字是在这个时刻收到的网络数据大小,大致的示意图如下:


图9:接收码率统计示意图


计算码率只需要将红框中所有的数字加起来,当时间发生改变后,就红框就向右移动并且填写新时刻接收到的数据大小,等下一个统计时刻既可。


5 feedback


前面介绍的estimator依赖于feedback反馈的报文到达时刻和丢包率来进评估码率的,也就是说feedback需要将这些信息及时反馈给接收端,主要是记录的报文到达时刻、通道丢包率和remb带宽。因为报文到达时刻和丢包率统计都是多个数据项,WebRTC利用了report block来进行编码存放。为了有效的利用RTCP的report block空间,WebRTC采用了相对时间转换和位压缩算法来对到达时间序列做编码压缩。


除了report编码,feedback的周期也很重要,如果是单纯的remb反馈,一般是1秒一次反馈。但如果是需要反馈报文的到达时间,它会根据占用5%的target bitrate来计算发送feedback的时间间隔,计算流程如下:



feedback interval需要满足一个条件:50ms < interval < 250ms,这个条件中的 50ms< internal是为了防止interval太小造成发送feedback太过频繁而消耗网络性能,而interval < 250ms是为了防止feedback频次太低造成estimator反应迟钝。


6 总结


以上就是WebRTC拥塞控制和码率调节策略的5个过程,里面涉及到很多传输相关的技术,我在这里也是简单介绍了下其工作原理,很多细节的并没有描述出来,也很难描述出来,有兴趣的同学可以翻看WebRTC的源代码。如果觉得webRTC代码费劲,我照虎画猫将WebRTC的拥塞控制用C重新实现了个简易版本,但是去掉了padding,可到https://github.com/yuanrongxi/razor下载。


6.1 效果


WebRTC的GCC在网络适应上表现还是比较良好的,既然兼顾延迟,也能兼顾丢包,网络发生拥塞时在2 ~ 3秒内能评估出相对的码率来适应当前的网络状态,但是会造成短时间的卡顿。对于网络发生间歇性丢包,在2秒左右能将传输码率适配到当前网络状态。它在网络相对稳定且延迟较大的网络进行高分辨率传输时,视频很稳定,适合长距离延迟稳定的网络环境。在弱网环境下,WebRTC容易将码率降到很低而造成图像失真。


6.2 网络大抖动


对于乱序和抖动WebRTC的拥塞控制显得有点无力,如果抖动超过rtt*2/3时,基于kalman filter的带宽评估机制不起作用(不知道是不是我用错了);基于trendline滤波的评估机制波动很大,敏感度不够,不能完全反应当前的网络过载状态,尤其是在终端Wi-Fi拥挤的情况下,比较容易造成间歇性风暴。


6.3 延迟问题


WebRTC的pacer在传输大分辨率视频时,关键帧会引起大约200毫秒的延时,尤其是在移动4G网络下这个问题更加明显,海康威视工程师郑鹏提出了用H.264的intre_refresh模式来应对,在测试过程中确实比较适合WebRTC用来减少关键帧造成的延迟,但是intre_refresh是普通模式编码CPU的3倍左右,而且很多移动设备的编码器不一定支持。


总之,WebRTC的拥塞控制存在反应慢、怕抖动的特性,但是这块也是WebRTC改进最为频繁的模块,几乎每个版本都有新的改进。要彻底解决这样的问题,需要从视频编码器和网络传输进行融合来解决,以后我用单独的篇幅来介绍下这样的解决方案。


关于作者


袁荣喜,学霸君资深架构师,16年的C程序员,善于构建高性能服务系统和系统性能调优,擅长P2P通信网络、TCP/IP通信协议栈和鉴权加密技术,2015年加入学霸君,负责构建学霸君的智能路由实时音视频传输系统和网络,解决音视频通信的实时性的问题。


辛锋,工程硕士,目前在萍乡学院电子工程专业从事教育工作,18年教育教学经验,对机电控制、芯片编程、控制理论和人工智能有深入的研究。



LiveVideoStackCon 2018讲师招募



LiveVideoStackCon 2018是音视频技术领域的综合技术大会,今年是在10月19-20日在北京举行。大会共设立16个专题,预计邀请超过80位技术专家。如果你在某一领域独当一面,欢迎申请成为LiveVideoStackCon 2018的讲师,让你的经验帮到更多人,你可以通过speaker@livevideostack.com 提交演讲信息。了解大会更多详情,请点击 http://beijing2018.livevideostack.com/ 访问LiveVideoStackCon 2018官网,即刻享受6折优惠。

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