基于Linux的视频图像处理及其网络传输监控系统

2020-12-18李博文陈元枝姜文英

桂林电子科技大学学报 2020年3期

关键词：码率编码传输

李博文，陈元枝，姜文英

(桂林电子科技大学电子工程与自动化学院，广西桂林 541004)

目前，视频网络监控在国内外都有着广泛的应用和较大的市场，比如安防系统，在一些商场、居民区、街道、金融机构随处可见。在诸多应用场合使用的视频监控系统主要分为2大类：

1)模拟视频监控系统[1]。该类系统采用模拟信号线传输数据，信号易受外部干扰，一旦传输距离较远，视频质量将会受影响，出现卡顿、马赛克等现象，主要应用于监控范围较小的场合，且系统的可扩展能力较弱，存储信息量非常有限，施工复杂[2]。

2)数字视频监控系统。由于该类系统的开发厂商较多，并未做到标准统一化，致使视频设备不具有互换性，视频平台建成并交付后，平台和设备的损坏、更新、维修、维护只能由视频建设单位提供支持和服务[3-5]。

数字时代的计算机处理器与监控系统大多为传统的串口总线连接[6]，所以呈现出了一定的弊端，尽管系统图像处理功能与sensor本身采集功能已较为成熟，但监控端与PC端控制信号传输有限，易受到干扰，相对来说不够完善。如今，网络监控的引入，各种网络协议与网络设备逐渐完善，使得视频网络传输的带宽更足，传输的数据完整性更有保障。最近几年，随着嵌入式技术的快速更新，控制器各个功能日益完善，芯片集成度增高，使得微控制器本身的稳定性、扩展性、运算速度、内存管理系统等性能更加优秀[7-8]。

鉴于此，设计了一种基于嵌入式Linux的视频图像处理及网络传输监控系统。该系统相比数字监控方式，不仅减少了接口引线工程，而且在数据传输速度、系统性能等各个方面更加完备。在编码方面，因H.264在压缩算法方面强于M-JPEG[9]，H.264的压缩比一般能达到1∶70甚至1∶150以上，而M-JPEG压缩比一般小于1∶20，且由于高压缩率，经H.264方式压缩的图像数据量远小于M-JPEG，更利于实时传输。

1 系统硬件平台

硬件平台框架如图1所示。该硬件平台由视频采样端摄像头、HI3518E芯片[10]、串口调试器、有线网卡RTL8201F、USB接口等构成。为了实现视频采集、处理、网络传输的低成本，低功耗，并能在客户端实时监控，系统采用一款性价比较高，成本较低的ARM9架构芯片HI3518E。该芯片集成了ARM9内核CPU与DSP的双核处理器，搭载了AR0130摄像头、有线网卡RTL8201F等外设。

图1 硬件平台框架

该系统处理器内核为ARM926，540 MHz主频，32 KiB I-Cache，32 KiB D-Cache，集成视频分析加速引擎。DSP具有支持3D去噪、图像增强等视频与图形处理功能，支持视频缩放及8个区域的编码前处理OSD叠加；具有H.264&JPEG多码流实时编码能力，支持CBR/VBR/FIXQP三种码率控制方式，输出码率可控范围为0.002 ～100 Mibit/s。

视频采集前端的任务主要是利用AR0130摄像头获取视频流，采用H.264编码技术对视频流进行帧压缩，通过Socket网络编程技术将压缩后的数据流经WiFi或有线网卡传送到客户端。

2 系统软件平台搭建

2.1 移植并烧录U-boot、Kernel、Rootfs

U-boot、Kernel、Rootfs的源码获取一般有2种[6]：1)在官网下载原版，并进行移植修改；2)开发商针对目标板移植的简化版文件。根据需要配置本系统需要的内核模块，对内核进行裁剪。

图2 系统根目录命令行状态

系统根目录命令行状态如图2所示。将PC机上Ubuntu Linux中事先移植修改的Uboot、Kernel、Rootfs交叉编译成镜像文件，烧录到目标板中的SPIflash，启动系统进入根文件系统命令行下，在Ubuntu Linux中搭建TFTP服务器，打开搭建过程中定义的专用传输文件目录tftpboot，将应用程序传入目标板。

2.2 部署根文件系统

海思平台视频编码算法部分未开源，而是以ko文件、静态链接库或动态链接库方式提供，需要部署到根文件系统指定的目录，应用层代码才能正常运行，否则会提示找不到运行时所需要的文件。系统根目录下部署ko文件与动态库如图3所示。

图3 系统根目录下部署ko文件与动态库

3 视频监控系统服务端设计

3.1 视频输入VI(video input)部分

1)创建视频缓存池。视频数据缓冲池如图4所示。在Linux中，使用、释放内存都需要申请，同样地，采样的视频数据存放也需要申请内存，海思平台提供了视频缓存池机制。结合实际业务需要，创建合适的缓存块个数，块的个数不能少于实际项目需要的个数，如原始数据存放在缓冲块Am中，传入VI后，视频处理子系统(video process sub-system，简称VPSS)部分对数据进行裁剪、旋转、缩放等处理，根据后续模块的需求，对原始数据作不同运算，运算后的数据分别放入各自的缓存块中。

图4 视频数据缓冲池

2)视频输入设备工作方式。VI设备通道功能框图如图5所示。视频输入设备可配置2种工作方式：①工作在离线状态时，VI对摄像头传输过来的视频数据选择性地进行一系列运算，如对原始数据进行裁剪、覆盖等处理，并输出多路不同分辨率的数据；②工作在在线状态时，VI将传入的原始数据直接在芯片内部写入VPSS，不经过DDR，数据到达VPSS的过程中省去了对DDR的读写，节省了图像数据传输时间。这2种模式的切换在安装驱动时通过设置参数来进行配置，考虑到实时性要求，为了降低时延，本系统设置工作在在线模式下，VI配置方式为insmod hi35xx_sys.ko vi_vpss_online=1。

图5 VI设备通道功能框图

3.2 VPSS

图6为VPSS上下文结构。VPSS部分针对用户需求对图像进行去噪等预处理，再传入VPSS通道，在通道中进行缩放、翻转、覆盖、镜像等图像处理，最后将视频数据本地显示或者通过视频编码(video encorde，简称VENC)模块编码后发送至终端解码播放。

图6 VPSS上下文结构图

3.3 VENC

1)HI3518E芯片VENC部分是一个支持H.264/JPEG两种协议的编码器，主要分为AVC(advanced video coding)和JPGE两部分，本系统H.264的编码功能在AVC中实现，JPEG编码的实现在JPEG部分。视频码流在VENC中的处理过程可分为对视频源数据的接收，对视频数据进行区域处理，视频数据编码，视频流输出4个步骤。

2)编码通道处理模块如图7所示。编码通道用来实现图像的编码操作，由码率控制器和编码器配合完成视频图像编码。码率控制器用来调整编码时的编码速率，编码器完成编码功能。

图7 编码通道处理模块

4 视频网络传输

4.1 实时流传输协议

实时流传输协议(real time streaming protocol，简称RTSP)[12]适用于CS(client server)架构。目标板作为服务器，PC机为客户端，目标板与PC机之间可以双向传输控制信号，以此来操作视频流的传输。RTSP工作在应用层，基于TCP协议之上，传输过程由RTSP协议主动发起流媒体后，通过RTP网络协议将视频流数据传送出去，而RTP/RTCP协议是基于UDP/TCP协议传输数据。视频数据和RTCP协议通过UDP/TCP协议传输数据，RTSP协议的控制流部分通过TCP传输。

4.2 实时传输协议

RTSP协议主要负责服务器与客户端之间的控制流信息交互，而真正发送数据依托于实时传输协议(real-time transport protocol，简称RTP)。RTP主要负责对编码码流数据按一定格式进行打包，在视频监控系统中一般与UDP协作，基于UDP协议来完成数据传输，所以传输过程只考虑数据的实时性，并不能保证数据的完整性。图8为RTP/RTCP协议网络流程图。

5 系统测试

本系统采用目标板Hi3518Ev200作为Server端，操作系统版本为Linux3.4.35。Client端采用PC机，Windows7 64位操作系统，通过安装虚拟机运行Ubuntu16.04版本的Linux系统，建立交叉编译工具链后，编译应用层C语言代码，生成系统运行时的可执行文件。

5.1 视频质量测试

1)调节Sensor，驱动黑电平[13]参数。黑电平参数取值范围为[0，255]，当黑电平标准被调高，图像将变亮，反之，图像变暗。图像亮度对比如图9所示。

从图9可看出，黑电平值为0时，图像明显偏暗，为255时亮度又太高，过于刺眼，经调节后，设置为200时，图像亮度适中，较为柔和。图10为黑电平值为200时的图像亮度。

2)设置FIXQP模式下I帧、P帧宏块QP值。QP值越低，其量化步长越小，图像质量越高，图像信息越丰富，对于处于运动过程的复杂画面，QP值较低时，编码码率超过系统上限，码率控制失效，画面会出现花屏、卡顿等现象,QP取值范围为[0,51]。不同QP值图像效果对比如图11所示。通过多次测试，最后选择I帧、P帧QP值为[20，24]，此时为本系统测试最佳效果。图12为QP值为[20，24]时的图像效果。

5.2 视频压缩率测试

选取一组运动画面的中间帧进行视频压缩率测试。图13为H.264分析器解析图像帧集合，number为69表示I帧压缩后的size，number为70～85表示P帧压缩后的size，number为66、67、68分别表示H.264格式中的SPS、PPS、SEI参数。

压缩前，一帧RGB图片占用内存大小为2 764 800 Byte，转换成YUV420格式后，每个像素占用1.5 Byte，一帧图像大小为1 382 400 Byte，参考帧I帧压缩比较低，H.264分析器NAL_Size显示压缩后的数据大小，通过对1 s内的30帧压缩图片求均值，计算得出每帧图片大小约为12 920 Byte，对比压缩前后图片所占内存大小，通过计算得到压缩率约为1∶107。

图9 图像亮度对比

图10 黑电平值为200图像亮度

图11 不同QP值图像效果对比

图12 QP值为[20,24]时图像效果

5.3 RTSP网络传输速率测试

本测试监控播放一段约10 min的视频，打开Wireshark[14]软件工具协议分层统计，如图14所示，

图13 H.264分析器解析图像帧集合

Server发送的数据包包括TCP协议包、RSTP协议包、ICMP协议包、UDP协议包，传输过程发送169 035个数据包，占232 017 121 Byte，整体传输速率为3.409 Mibit/s，转换为字节为426.125 KiB/s，其中99.86%的数据包为视频流数据，即168 798个包通过UDP发送，且数据传输比特率为3.408 Mibit/s，即426 KiB/s。RTSP协议包占5个包，共1 335 Byte。图15 为网络传输速率分布。从图15可看出，服务器平均每秒发送字节约为426 KiB。