地铁车载高清视频播放系统的优化

2018-09-18赵旭峰

天津工业大学学报 2018年4期

白华，赵旭峰

（天津工业大学电子与信息工程学院，天津 300387）

地铁车载视频播放系统作为一种媒体服务平台，为乘客提供高效、快捷的服务.随着多媒体技术的快速发展，乘客对车载视频画质的清晰度、流畅度和分辨率等提出了更高的要求，这就必然给服务器与传输网络带来巨大的运行压力[1-2].

目前，国内地铁车载视频播放系统虽然可以播放高清视频，但仍然存在一些问题：服务器普遍采用传统的H.264作为视频编码方案，但是由于H.264编码标准的算法复杂度较大，导致视频压缩编码时间加长，最终在视频终端出现了时间的延迟；网络传输协议采用UDP（用户数据报协议），然而UDP自身的非连接性造成网络环境不稳定时数据包丢失，造成显示端出现黑屏、播放不流畅等问题；综上所述，有必要优化H.264视频编码方案和网络传输方案以满足乘客对画面质量的要求[3].

基于上述问题，本文提出了基于应用层优化的UDP作为网络传输协议，并且对H.264帧内预测算法和编码选项进行优化，在此基础上设计一种基于ARM+Linux的地铁车载高清视频播放系统.本系统实现基本流程为：服务器读取本地存储器（SD卡）的预存视频，采用优化H.264编码标准对视频压缩编码，使用改进的UDP实现将编码后数据发送到客户端，客户端使用FFMPEG对视频数据解码且在LCD屏实时播放，实现720 P和1080 P高清视频的播放功能.该系统可以适应由于地铁车厢震动造成的网络突变且能够有效节约网络带宽.不仅可以适用于地铁车载领域，同样在公交车载系统、客户服务大厅等场所也有着较好的适用性，具有良好的应用前景.

1 视频编码方案的选择与优化

H.264是在混合编码的框架上引入了新的编码方式，适用于交互式和非交互式应用环境.与其他编码标准相比，H.264具有较高的压缩比和较强网络亲和能力，可以适应地铁网络环境突变[4]，所以在车载服务器视频编码方案优先选择了H.264.然而，H.264存在较高的运算复杂度，无法在有限的硬件平台充分的发挥其优秀的编码性能.H.264运算复杂度主要来源2个方面：算法复杂度和庞大的编码选项[7].本文针对H.264帧内预测算法和编码选项优化，力求在保证编码精度的同时降低编码时间和减小运算复杂度.

本文选用H.264编码器为x264.与JM和T264编码器模型相比，x264编码器具有较强的实用性，现已成为应用范围最广的视频图像编码器[7].帧内预测算法和编码器选项研究如下.

1.1 帧内预测算法优化

帧内预测算法亮度块预测分为4×4块和16×16块，亮度块4×4块有9种预测模式，16×16块有4种预测模式；色度预测8×8块有4种预测模式；因此，对于任一个宏块都要 M8×（M4×16+M16）=592次计算才能找到最佳的预测模式，大量的计算带来运算复杂度的进一步增加[5].文献[8-10]提出利用纹理特性来选择最佳的预测模式，但是没有考虑块之间的联系，可能导致图像清晰度变低.考虑到宏块本身平坦度特征的关系，即平坦区域适合于16×16块、细节区域适合于4×4亮度块[4].文献[11]提出采用宏块灰度直方图作为宏块平坦判1断标准，但是计算复杂且码率无法达到实际要求.

基于以上问题，本文提出了基于SATD（绝对变换误差和）和图像本身特性结合的一种新型的亮度块判决算法.算法的基本流程如下：将当前宏块16×16块划分为16个4×4块.首先，计算4种16×16块模式下的代价函数，选择代价函数最小值作为最优的模式记为Cost16；然后，比较Cost16和T0的关系（T0为设定的阈值，T0为采用不同序列测试后得到16×16块的平均SATD值为800，故设定T0=800），若Cost16小于T0，则选16×16为最优模式；反之，则分别计算16个4×4块在9种预测模式的最小代价函数值，选定最小值为最优模式并且计算16个最小的代价函数和记为Scost4.最后，若Scost4＜Cost16，选择4×4块为最优模式；反之，则选择16×16块预测模式.图1为优化后亮度块判决算法的基本流程图.

图1 亮度块预测模式判决流程图Fig.1 Decision flow chart of brightness block prediction mode

1.2 编码选项优化

由于车载视频在相邻帧具有背景固定，前景运动画面较少的特点.以视频压缩编码压缩性能指标如PSNR（峰值信噪比）、编码帧率为依据优化编码选项，在保证图像主观质量与码率、网络带宽相适应的前提下，尽可能提高编码速率[6].

PC机测试硬件平台采用主频为1.5 GHz的处理器，型号为Intel（R）core（TM）i5-6300HQ；软件平台为Ubuntu12.04的操作系统、编码器版本为x264-snap-20170424-2245.采用不同分辨率的视频，多次实验选择面向地铁环境的最佳编码方案如下：

（1）x264编码档次采用不使用熵编码的基本档次；

（2）考虑地铁网络环境突变，选择输出帧率为15 fps，选择码率 128 kbps；

（3）编码参考帧使用一个参考帧；

（4）运动估计宏块搜索模式设置为 DIA（diamond）、搜索范围设置为8.

1.3 性能测试

分别对5种不同分辨率的视频压缩编码，其中，缺省为优化前的状态，为了分别衡量峰值信噪比和帧率在缺省状态和优化后的变化关系.本文采用信噪比损失率和帧率提高率两个指标来衡量，测得编码方案优化前后不同分辨率视频的PSNR和编码帧率信息如表1和表2所示.

表1 编码方案优化前后测试序列PSNR比较Tab.1 Comparison of PSNR of test sequence before and after coding scheme optimization

表2 编码方案优化前后测试序列编码帧率比较Tab.2 Comparison of frame rate before and after coding scheme optimization

由表1、表2可以看出，峰值信噪比在缺省状态和优化后相差很小，编码方案优化后峰值信噪比损失都很小，说明编码方案优化对于视频失真较小；然而编码帧率在优化后几乎为缺省状态的2倍，编码方案优化后帧率提高均在1倍左右，在保证视频编码质量的同时缩短编码时间，达到了预期的目的.

2 传输网络协议的选择与改进

TCP和UDP作为提供通信服务的重要的协议，在数据传输过程中扮演着重要的角色.TCP是面向连接在传输层最为广泛应用的可靠协议，但是TCP由于重传机制和流量拥塞机制引入的抖动使其无法有效的应用于音/视频数据的传输[12].UDP主要用于海量数据的传输，具有较高的传输效率，然而由于UDP传输的非连接性，在地铁网络环境不稳定时容易出现丢包和错包的现象，导致视频终端出现长时间的花屏甚至黑屏[13].

2.1 协议优化

针对UDP在视频传输的不足，文献[14]提出的可靠UDP虽然可以明显降低丢包率，但是其实现在网络层且灵活性较差，无法应用于地铁突变的网络环境.文献[15]提出优化UDP的方案在应用层加入了视频缓冲区、流量控制和确认机制等，虽然可以保证可靠传输，但是复杂度较高，无法保证有效传输.

本文在此基础上提出基于应用层的优化UDP的方案：在TCP/IP协议簇的应用层加入优化的UDP控制机制，除了具有发送和接收功能以外，还加入了重发和补发等机制，其具体实现在应用层，具有灵活性强、算法简单等优点，在地铁网络传输具有较高的应用价值.

首先，发送端建立等待队列和重发队列[15]，等待队列用来存放已经发送的数据，重发队列存放需要重新发送的数据包.之后当服务器收到来自客户端发来的重发控制包时，根据重发控制报文的内容，在等待队列中找到需要重新发送的数据包放入重发队列，同时在等待队列中将客户端已经收到的数据包进行释放，若某一个数据包发送5次以上客户端都没有收到，则可以将该数据包丢掉；最后发送重发队列中的数据包，依次循环完成数据包的发送.图2为服务器采用优化UDP发送数据包流程图.

图2 优化UDP发送数据包程序流程图Fig.2 Flow chart of transmission packet using optimized UDP

2.2 协议测试

分别对优化后UDP和UDP传输协议测试比较：服务器将已编码的H264文件（240帧1280×720的高清序列）分别使用UDP和优化UDP采用socket编程将数据通过以太网发送至客户端，客户端统计收到数据包的具体情况.实验室测试时，通过将网线内部的一组输入和输出的导线短接，以模拟地铁突变且不稳定的网络环境.分别在相同的网络环境下，重复10次实验得到如图3所示.

图3 不同协议客户端接收数据包情况Fig.3 Client receive data packets using different protocol

从图3可以得出，当网络环境较差时使用优化的UDP协议，客户端收到视频平均帧数为221.2帧，平均丢包率为7.83%；使用UDP协议，平均帧数为190.1帧，平均丢包率为20.79%，优化后丢包率减少62.33%.由于地铁大部分时间处于稳定的网络状态，只有在经过隧道时网络才会发生突变.实验室模拟在网络较差的情况下，客户端可以接收到大约93%的数据包且画面显示流畅.然而地铁实际网络环境要远优于实验室模拟的情况，所以优化的UDP可以在地铁视频传输网络得到广泛的应用.

3 系统方案设计与平台搭建

3.1 系统整体方案设计

本系统主要由服务器、视频传输网络和客户端3个模块组成，其中服务器、客户端是运行在A20硬件平台嵌入式Linux系统，视频传输网络采用基于应用层的UDP协议，3个模块协调配合完成高清视频播放的功能[16].

服务器的主要功能是读取本地SD卡的视频数据，将读取的数据放入缓冲区后，以数据帧的形式对缓冲区的视频数据编码，然后将编码后的数据封装、打包发送至以太网.以优化后H.264编码算法对高清视频的压缩编码，该算法可以在保证编码压缩比的同时，有效的缩短编码时间，减小了地铁高清视频播放系统因为编码时间带来的局部时延.

视频传输网络主要是通过以太网将数据由服务器发送到客户端.传输协议采用基于应用层的UDP协议，减少了由于网络环境不稳定而造成的视频数据丢包和错包等现象.

客户端主要接收由以太网传输的数据流，解封装后调用FFMPEG对视频流解码，使其还原为未经压缩处理过的数据流，然后将数据输出到终端在LCD实时流畅的播放.图4为系统整体设计流程图.

图4 系统整体流程图Fig.4 Flow chart of system

3.2 系统平台搭建

本系统服务器和客户端采用CPU主频为1.6 GHz的ARM Cortex-A7双核处理器，图像处理器采用了ARM Mail40MP2的双核GPU，支持2160 P视频解码和1080 P视频编码的全志A20芯片.该芯片是基于“CPU+多媒体协处理器”双核处理器，具有成本低、功耗低、功能灵活、便于升级等特点，因此在本系统硬件设计过程中优先选择A20芯片[14].

该系统硬件电路采用核心板+底板的架构.核心板主要由处理器、存储器和AXP电源管理电路等组成，作为整个系统的控制和处理单元.底板主要由外围电路和扩展接口组成，主要包括供电电路、高清视频显示接口、USB、以太网和SD卡接口等[17].

软件平台采用Linux操作系统.系统开发模式采用“宿主机+目标机”，分别在宿主机和目标机搭建软件平台.宿主机（PC）软件平台搭建主要包括建立交叉编译环境、安装SSH服务器和Samba服务器等，主要保证宿主机和目标机正常通信；目标机软件平台主要包括Bootloader（引导加载程序）的移植，Linux内核移植、构建根文件系统等[18].

本文采用U-Boot的版本号为u-boot-2011.09-rc1，内核版本号为Linux-3.4.根据实际需求，裁剪和修改源码，然后将宿主机交叉编译后得到u-boot.bin、内核镜像文件移植到目标机即刻完成软件平台的搭建.为了实现视频编解码功能，分别在服务器和客户端移植优化后x264编码器、FFMPEG解码器[18].

4 系统测试

4.1 系统测试平台

本系统测试平台采用2套A20目标板，分别模拟服务器和客户端，二者通过网线相连.目标板采用内核版本号为3.4.39的Linux系统，高清视频编码器版本x264-snap-20170424-2245，解码器版本为FFmpeg-3.3.1；宿主机交叉编译版本为arm-linux-gcc-4.4.3.系统上电后，首先将服务器和客户端的IP设置为同一网段；其次，启动应用程序可以得到如图5所示的高清视频1920×1080播放的效果图.

图5 测试效果图Fig.5 Results of testing

4.2 测试结果与分析

本文采用PSNR和SSIM（结构相似比）作为视频质量的评判标准.首先在Linux系统采用FFMPEG工具分别将SD卡和解码后视频转换为帧图像；之后采用MATLAB编程计算2个视频对应帧图像之间PSNR和SSIM；最后取平均值作为视频相似度的标准.表3列出不同分辨率视频相似度和平均帧率信息.

表3 不同分辨率视频的PSNR和SSIMTab.3 PSNR and SSIM for different resolution video

针对高清视频而言，由表3可以得出如下结论：根据结构相似度信息可知，解码后和未压缩前视频的相似度近似为0.98，可见视频在传输过程中丢包较少，满足丢包率小的要求；由峰值信噪比信息可知，PSNR的平均值都在33 dB以上，说明了视频失真较小；由帧率平均值在27 fps以上，可以看出视频终端画面显示流畅，解决了画面卡顿的问题.

综上所述，该系统在播放过程中画面流畅、清晰，实现了系统播放高清视频的功能.