屏幕直播系统延迟优化①

付鹏斌,任 衡,杨惠荣

(北京工业大学 信息学部,北京 100124)

智能手机的出现和移动互联网的崛起为观看清晰的直播提供了基础保障,然而,随着直播并发量的骤增、网络传输的不确定性等原因,在直播时会产生不同程度的画面延迟.市面上基于HLS(HTTP Live Streaming)[1]协议的直播,理论延迟在10 s～30 s 之间,基于RTMP (Real Time Messaging Protocol)[2]协议的直播在多终端播放条件下延迟在5 s～10 s 之间,无法满足实时直播的需求.所以如何降低直播延迟,增强直播的实时性体验成为一个关键性的技术挑战.

本文通过分析直播的各个环节,从网络推流、首帧打开时间、视频编码三个角度进行了直播延迟优化.一是依据网络状况自适应调整直播推流码率,优化推流策略；二是设计实现关键帧缓存算法,降低首帧加载延迟；三是对x264 算法帧内预测部分进行改进,降低编码延迟.最终实现了一个低延迟的屏幕直播系统,增强了直播的实时性体验.

1 网络自适应推流

网络自适应推流的作用是在网络波动较大的情况下,根据网络带宽条件调整码流,使得视频播放保持整体流畅.视频码率越高,视频质量越好,对网络带宽的消耗就会越大.因此当弱网络带宽不足的情况发生时,如果不对分辨率码率等参数进行调整,将会造成推流上行网络的负载加大,进而造成直播延迟.

1.1 网络质量评价

网络质量由上行网络平均带宽和平均往返时延两个指标确定,它们共同反映网络的传输状况.

上行网络平均带宽的值越大,代表网络状况越好.它的值由Jpcap[3]获取,检测过程如下：

(1) 获取网络接口列表：调用函数库中的getDevice List()方法获取本机网络接口列表.

(2) 打开网络接口：调用openDevice()方法对网络接口进行监听.设置每次最大捕获数据包大小为65 535 Byte、开启混杂模式接收所有类型的数据包、捕获数据包超时时间设置为50 ms.

(3) 捕获数据包：定义类MyPacketReceiver,它实现了PacketReceiver 接口,并实现接口中的receivePacket方法,然后调用loopPacket() 方法捕获数据包,获取数据包后会回调receivePacket() 方法对数据包做处理.

(4) 实时计算上行网络平均带宽：统计60 秒内所捕获的源IP 地址为视频采集端的数据包大小,计算上行网络平均带宽.

(5) 定时任务每隔10 min 重复步骤(3)和步骤(4).

平均往返时延的值越小,代表网络状况越好.它的值可以通过java 编程语言调用cmd 命令“ping ip Address -n pingTimes -l length”获取,ipAddress 为Ngnix-rtmp 服务器主机IP,pingTimes 为向服务器发送的请求个数,length 为每次发送的数据包大小.

使用网络模拟工具Clumsy 调整网络状况,利用上行网络平均带宽和平均往返时延两个指标建立了表1三种网络质量模型.

表1 网络质量模型

1.2 自适应推流

每隔一段时间对网络状况进行检测评价.当网络优秀时,缓慢提升采集帧率和分辨率；当网络良好时,保持原状,不改变帧率和分辨率；当网络较差时,大幅降低采集帧率和视频分辨率,自适应过程遵循“快降慢升”的原则.网络自适应推流策略如图1所示.

图1 网络自适应推流策略

如表2所示为6 种推流方案所对应的帧率和分辨率.“快降慢升”的含义即当网络状况较差时,将当前推流方案减2.比如当推流端按照25 Fps@1280×720 推流时检测到网络较差,大幅度降低帧率和分辨率,调整为按照15 Fps@800×600 方式推流,减小对网络带宽的压力；当网络状况优秀时,若当前推流方案小于6 时,则推流方案加1,若当前推流方案为6,则保持不变.比如当推流端按照20 FPS@1024×768 推流时检测到网络优秀,缓慢增加帧率和分辨率,按照25 FPS@1280×720方式推流.

表2 不同推流方案对应的帧率和分辨率

2 首帧延迟优化

2.1 首帧延迟

直播是实时视频流,用户以一个随机的时间点接入视频流进行播放,接入时第一帧帧类型若不是关键帧[4],此时播放缓冲区为空,解码器无法解码只能丢帧.播放器等到下一个关键帧才能播放,等待时间若大于5 秒,会影响用户体验.如果接入直播流时首帧正好是关键帧,则可以快速显示首帧画面.

2.2 关键帧缓存算法

为此,服务器对关键帧进行缓存,缓存过程如下：

(1) 推流端开启双路推流,一路视频流推送到服务器,一路视频流定时推送flv 小段视频到本地.

(2) 读取本地最新flv 视频小段并解析.

(3) 遍历每一个FLV Tag[5],获取FLV Tag header[5]的第一个字节,判断值是否为0x09 即视频类型,若是则进入第(4)步,否则遍历下一个FLV Tag.

(4) 获取Tag header 的第二到第四个字节,计算视频数据长度length.

(5) 获取Tag data 的第一个字节前4 位,若值为0001 则为关键帧,从第二个字节开始获取长度为length的关键帧数据,若不是关键帧则遍历下一个FLV Tag.

(6) 查看缓存队列是否含有关键帧,没有则缓存,有则更新.

(7) 播放端从服务器内存中先请求关键帧进行播放,再请求正常的视频流.

2.3 实验测试及分析

由于校园网白天和晚上的网络流量是不同的,为了检验算法在不同网络条件下的效果,实验统计了校园网白天(10：00～17：00)和晚上(19：30～23：00)两个时间段的三种视频分辨率(1920*1080、1280*720、800*600)下的首屏打开时间,每种视频分辨率下,共进行200 次点击播放操作,记录每一次从点击播放到首屏画面加载出来的时间.实验结果如图2、图3、图4所示.

图2 首屏打开耗时对比(视频分辨率1920×1080)

图3 首屏打开耗时对比(视频分辨率1280×720)

图4 首屏打开耗时对比(视频分辨率800×600)

对实验结果进行分析,当视频分辨率为1920×1080 时,如图2所示,白天和晚上,优化前首屏打开时间均在15～25 秒左右,优化后首屏打开平均时间,白天为3133 ms,晚上为3010 ms；视频分辨率为1280×720 时,如图3所示,优化前首屏打开时间在10～25 秒左右,优化后首屏打开平均时间,白天为3241 ms,晚上为3150 ms；当视频分辨率为800×600 时,如图4所示,白天或晚上均在10 s 以上,优化后白天平均首屏打开时间为2864 ms,晚上为2915 ms.首屏打开时间明显降低,提高了接入直播画面的速度.

此外,观察折线图的走势,如图2(a)中优化前有3 次首屏打开时间在 5000 ms 以下,图2(b)中优化前有2 次首屏打开时间也在5000 ms 以下,图3～图4中也出现类似的情况.这是因为用户以一个随机的时间点接入直播流,若首帧正好是关键帧,则可以快速加载播放.未优化前,进行200 次点击播放操作,仅有10 次以下能做到快速打开,具有随机性,进一步说明了利用关键帧缓存算法对首帧打开时间进行优化的必要性,该算法保证了首帧正好是关键帧,避免了首帧类型不确定所导致的首屏长时间等待.

3 编码延迟优化

3.1 H.264 帧内预测及模式选择

H.264 中4×4 亮度块有9 种预测模式,16×16 亮度块和8×8 色度块都各有4 种预测模式[6,7].每一种宏块的帧内预测模式选择都是遍历所有的预测模式,找到率失真代价值最小的模式作为最优帧内预测模式进行编码,计算复杂度较大.

3.2 x264 帧内预测分析

x264 是开源且大规模商用的视频编码器[8,9],因此本文选择x264 作为屏幕直播系统的实时编码器.

H.264 标准中帧内预测模式的选择采用全搜索算法,计算复杂度较大.x264 针对预测模式全搜索算法做出了优化：x264 中在对4×4 块9 种预测模式进行循环遍历时采取提前终止策略,提前退出循环终止计算.以下对x264 算法的优化即在这个基础上通过减少候选模式的数量进一步减少计算复杂度.

3.3 帧内预测模式快速选择算法

对于4×4 宏块,基于图像的纹理方向,降低候选模式的数量.具体的算法流程和代码如下：

(1) 定义4 个视频纹理方向0°,45°,90°,135°,用变量Angle0、Angle45、Angle90、Angle135 表示[10].

(2) 将4×4 亮度块平均分成4 个2×2 的子块,它们的像素按照行优先的顺序分别表示为S1、S2、S3、S4,每个像素值由其包含的4 个像素求均值得到[10].

int16_t S1=(*(p_src_by)+*(p_src_by+1)+*(p_src_by+16)+*(p_src_by+17))＞＞2；

int16_t S2=(*(p_src_by+2)+*(p_src_by+3)+*(p_src_by+18)+*(p_src_by+19))＞＞2；

int16_t S3=(*(p_src_by+32)+*(p_src_by+33)+*(p_src_by+48)+*(p_src_by+49))＞＞2；

int16_t S4=(*(p_src_by+34)+*(p_src_by+35)+*(p_src_by+50)+*(p_src_by+51))＞＞2；

其中,p_src_by=p_src+block_idx_xy_fenc[idx],p_src 为编码帧,idx 为16 个4×4 块的序号,经过计算得出宏块所包含的第一个4×4 块的左上角元素首地址即像素A 的地址p_src_by.

(3) 计算纹理系数Angle0、Angle45、Angle90、Angle135.

int16_t Angle0=abs(S2-S1)+abs(S4-S3)；

int16_t Angle45=abs(S1-S4)+abs(S4-S1)；

int16_t Angle90=abs(S1-S3)+abs(S2-S4)；

int16_t Angle135=abs(S2-S3)+abs(S3-S2)；

(4) 计算八种预测模式的纹理方向值,对应关系如表3所示.

表3 八种预测模式对应的纹理方向值

(5) 对纹理方向值进行排序,选取纹理方向值最小的两种模式作为候选模式.此外,如表4所示,四种视频序列在实际编码中使用频率最高的是模式0～模式2,故将这三种模式也作为候选模式.考虑到纹理方向值最小的两种模式可能已包含模式0 或者模式1,故最终的候选模式最少3 种,最多5 种.

(6) 对3～5 种候选模式进行率失真代价值计算,选取值最小的预测模式为最优的预测模式.

表4 4×4 亮度块9 种预测模式编码使用比例(%)

3.4 实验测试及分析

由于文章已实现了网络自适应推流,使得输出码率大小与网络相适应,视频编码算法的优化主要关注编码速度和视频质量.编码速度由编码帧率和编码时间来衡量,编码帧率越大、编码时间越短则算法效果越好.图像客观质量psnr[11]值越大表示图像质量越好.

3.4.1 编码参数确定

屏幕直播系统编码参数设置如表5所示.

表5 屏幕直播系统编码参数

3.4.2 改进的算法实验对比

在屏幕直播系统中录制500 帧YUV(4：2：0)格式的ppt 教学视频,视频特点是视频变化较为平缓,局部纹理细节丰富,能代表屏幕直播系统中大部分应用场景的视频特点.此外,选择与该视频特点相似的两个官方测试序列news和highway 进行测试.

对三种视频序列的编码时间变化率(△time)、编码帧率变化率(△fps)、图像客观质量变化(△psnr)进行比较,计算方法如下：

将3 种测试序列实验结果按照式(1)～(3)进行计算,最终3 种序列的测试结果如表6所示.

表6 改进x264 算法与未改进x264 算法比较

从实验结果可以看出,改进后的x264 算法压缩屏幕直播系统中的ppt 视频序列,编码时间下降了8.26%,编码帧率提高了8.79%.对于官方测试序列,news 序列编码时间下降3.74%,编码帧率提高4.16%；highway序列编码时间下降了21.94%,编码帧率提高了27.9%.3 种序列视频质量基本没有损失.改进后的x264 编码算法应用到屏幕直播系统中,有效的降低了编码时间,提高了编码的效率.

4 系统延迟测试

基于以上研究,设计并实现屏幕直播系统,系统总体架构分为推流端、流媒体服务器、播放端、业务服务器四部分.运行屏幕直播系统,使用13 台平板电脑(内存2 GB)进行播放,统计系统在800×600、1024×768、1280×720、1920×1080 四种分辨率下的直播延迟情况.网络路由器为华为企业级路由器AR111-S,AP 为华为无线AP 3010DN-V2.推流端和服务器为笔记本电脑,CPU 配置信息为Intel(R) Core(TM)i5-3230 M,双核2.6 Ghz,内存为8 GB.

每隔100 帧视频统计一下直播延迟,一共测试50 次共计5000 帧,将直播延迟数据实时写入SD 卡的文本文件中,最终的实验结果如图5所示.

图5 屏幕直播系统在四种分辨率下的延迟测试结果

对实验结果进行分析,当推流分辨率为800×600、1024×768、1280×720 时,系统延迟稳定在1 s～3 s 之间.与优化前5 s～10 s 的延迟相比,经过优化后的屏幕直播系统在1280×720 甚至更低分辨率下延迟较低,能够满足实际教学中课堂屏幕共享需求.对于1920×1080超清分辨率的屏幕直播,系统的延迟较高且随着播放帧数增多产生累积延迟,出现延迟上升的趋势,后续工作需要进一步研究超清视频序列的特点,有效地降低超清视频直播场景下的系统延迟.

5 结论与展望

如何在现有直播架构下进行直播延迟优化对增强用户实时性体验有很大的现实意义.文章从网络推流、首帧延迟、编码延迟三个角度对直播延迟问题进行分析和优化,实现了低延迟的屏幕直播系统,并将该系统应用于课堂屏幕共享教学中,能高效实时的进行课件展示、应用软件教学等操作,提高了课堂效率,具有很高的应用价值.