视频云直播端网络QoS算法总结和技术展望

一、概述

由于从直播端到RTMP服务器的网络情况复杂，尤其是在3G和带宽较差的Wifi环境下，网络丢包、抖动和延迟经常发生，导致直播推流不畅。RTMP基于TCP进行传输，TCP自身实现了网络拥塞下的处理，内部的机制较为复杂，而且对开发者不可见，开发者无法根据TCP协议的信息判断当时的网络情况，导致发送码率大于实际网络带宽，造成比较严重的网络拥塞。

由于TCP本身是面向连接、可靠地传输层协议，关于RTMP协议的网络QoS讨论较少，所以本文的QoS策略完全是通过不断实验和摸索设计开发的，如有问题欢迎指正。

二、视频云直播端QoS策略

由于上述原因，我们在研究解决直播端的网络拥塞问题时，根据实验结果进行分析，以发送一帧视频数据的时间为依据，判断当前网络拥塞情况。

2.1 策略依据的原理

如图1所示，TCP协议在发送数据时，首先将应用层(采用librtmp标准库)下发的数据缓存在sendbuffer中，然后应用层函数的调用返回，函数的调用是瞬间完成的。TCP协议何时从sendbuffer中取出数据进行发送是由TCP协议本身和当时的网络情况所决定的。如果网络中出现丢包和抖动，导致接收端接收数据超时，会激发发送端数据重传，重传机制本身挤占网络带宽，导致sendbuffer中的数据进一步发送失败，致使sendbuffer中的数据不断增多，达到上溢的警戒线，此时应用层函数下发数据到sendbuffer就不会瞬间完成，而是会等待sendbuffer中的数据低于警戒线，再将数据下发。

图1 TCP发送数据示意图

    因此，可以根据应用层函数写数据到sendbuffer的时间来判断网络的拥塞情况。

2.2 QoS算法1.0版本

2.2.1实现过程

    QoS算法1.0版本具体的实现过程是：在网络带宽受限（采用路由器限制）的情况下，测试函数av_interleaved_write_frame的运行时间，如果时间大于阈值1，则认为网络很差，大幅度降低QoS level；如果时间小于阈值1，但是大于阈值2，则认为网络一般差，小幅度降低QoS level；如果连续一段时间，函数的运行时间都小于阈值2，则认为网络情况较好，可以考虑小幅度提高QoS level。

    其中，函数av_interleaved_write_frame就是前述的应用层向TCP send buffer下发数据的函数。

    算法基本流程如图2所示。

       图2 QoS算法1.0版本基本流程图

2.2.2 实验结果

    测试环境：路由器500kbps限速的实验室环境和联通3G的实际环境下。

    测试设备：魅族MX3手机，SDK版本：4.2.1。

    测试结果如图3和图4所示。其中，横坐标是时间，单位是秒，每秒计算一次数据，并采样画图。纵坐标是码率，单位是kbps。

    系列1代表视频实际发送码率，系列2代表音频实际发送码率，系列3代表总的发送码率，系列4代表QoS设置的视频发送码率。

 

图3 500kbps限速下的QoS算法实验结果

图4 联通3G下的QoS算法实验结果

    如图3所示，当出现网络拥塞时，视频和音频的发送码率都降为0，视频和音频的发送线程都被函数av_interleaved_write_frame挂住，直到该函数返回，QoS才开始发挥作用，进行发送码率的调节。此时，可以看到系列4曲线出现较大幅度的降低，表示设置的发送码率开始降低。。

    然后，网络出现一段时间的平稳期，QoS算法开始向上调节网络的发送码率。

2.3 QoS算法1.1版本

    在QoS 1.0版本基础上，通过引入微软的网络模拟工具network emulation windows toolkit，进行10分钟的相同视频源的测试，发现QoS 1.0算法的一些问题，并在此基础上进行优化。

2.3.1实验结果

    测试环境：在Win7笔记本电脑上开wifi热点，使用network emulation windows toolkit对wifi对应的网卡进行模拟限制。

    测试设备：Meizu MX3手机。

    如表1所示，列出了测试的项目，包括丢包、带宽限制和延迟三种单独测试项，和模拟的3G真实环境。

    测试数据如图5、6所示，其中系列1是视频实际码率，系列2是设定的视频码率。

图5 random 15%丢包下的对比图

图6 200k带宽限制下对比图

      如图5和6所示，QoS 1.1相比QoS 1.0，实际视频码率（系列1）降低到0的次数明显减少，说明卡顿相应减少。

    主要原因是，针对QoS 1.0算法调节过于频繁，码率经常上探的问题，在QoS 1.1算法中增加QoS Level之间的barrier，防止频繁上探。

2.3.2实现过程

    QoS 1.1算法的实现基于以下假设：

（1）从高一级Level降到低一级Level越频繁，说明当前网络只支持低一级Level，应该减少从低一级Level上探的机会。避免卡顿。

（2）从高一级Level降到低一级Level，在高一级Level停留的时间越短，说明当前网络倾向于支持低一级Level。

（3）在高一级Level停留的越久，说明网络比较适合在高一级Level，此时应该削弱低一级Level到高一级Level的barrier。

（4）由于发送函数时间存在大小之分，决定了降低Level的强弱，强降低产生的Level间barrier应该高于弱降低产生的barrier。

（5）每两个QoS Level之间都存在barrier，在某一级Level上停留应该减弱下一级和下两级的barrier。

    算法流程图如图7所示。

     其中，菱形代表操作，长方形代表判断条件。writeFrameTime是写数据到sendbuffer的时间，barrier是上下两级码率设置之间的障碍，用来限制码率升级。

                            

                                                                    图7 QoS 1.1算法基本流程图

2.4 QoS算法1.2版本

    在QoS算法1.1版本对视频码率进行网络自适应调节的基础上，QoS算法1.2版本针对视频云直播端音视频线程进行了优化，使得在网络变差的情况下，音频推流得到一定程度的保障，改善播放端的音频播放体验。

2.4.1 视频云直播端线程背景介绍

    由于视频云直播端采用视频和音频两个独立线程执行采集、前处理、编码、打包发送操作，导致了在网络发生拥塞、数据发送不畅的情况下，音视频各自的采集和编码操作受阻，当网络恢复时，由于拥塞期间的数据没有被采集和编码，最终导致播放端出现卡顿。

    为了解决这一问题，对音频线程进行分离，分为音频采集、前处理、编码线程和打包发送线程。

2.4.2 视频云直播端线程交互流程

   以音频线程的调整为例，调整后的线程交互图如图8所示。

图8 视频云直播端线程交互图

调整后的流程分为音频采集、前处理和编码线程，以及音频打包发送线程。两个线程之间通过一组循环buffer进行数据传递。

如果网络发送出现拥塞，导致音频打包发送线程受阻，长时间没有从缓冲buffer中拷贝数据，最终导致缓冲buffer中没有空余位置可以接收新的编码数据，那么，音频编码后的数据将被丢弃。

2.4.3 测试效果

视频云直播端线程分离方案的测试效果如图9所示。

测试环境：树莓派 带宽限制330kbps

测试设备：华为Mate8手机

图9 视频云直播端线程分离方案测试结果（音频线程分离）

如图7所示，音频线程经过分离，在卡顿点（红色圆圈）位置，音频发送数据在网络恢复后能够完全发送，弥补了网络卡顿时的数据发送障碍，不会导致播放端的卡顿。

实际测试中，采用音频线程分离策略，播放器的转圈明显减少，视频卡顿时，音频依然流畅，主观感受得到很大的提升。

网易云新用户大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者崔承宗授权发布。