基于DM365的网络视频前端的设计与实现

2012-07-18戴鹏应时彦

杭州电子科技大学学报(自然科学版) 2012年5期

戴鹏军，应时彦

(1.浙江工业大学计算机科学与技术学院，浙江杭州310023;2.浙江工业大学信息工程学院，浙江杭州310023)

0 引言

随着网络技术和数字视频技术特别是流媒体技术的迅猛发展，视频监控系统技术的发展已经从最初的模拟视频监控系统发展到如今的网络数字视频监控系统［1］。相对于传统视频监控系统，网络数字视频监控系统在视频清晰度、流畅性、实时性等方面都有了更高的要求。网络视频前端不仅需要作为视频监控系统中的视频采集单元，而且需要集成包括数据处理，网络传输和信令控制等核心单元［2］。本文所设计的网络视频前端基于TI达芬奇技术的TMS320DM365芯片，支持D1(720×576)分辨率的实时视频，采用H.264/AVC视频编码标准。并且集成了视频数据RTP打包发送和SIP控制信令功能，提高了视频前端的系统兼容性和网络兼容性。

1 系统结构与原理

网络数字视频监控系统由网络视频前端、服务器和客户端3部分组成，其中视频前端和客户端可以有多个，如图1所示。视频前端是系统的数据捕获源，主要完成视频的采集编码和RTP打包发送到服务器;服务器是系统的指挥中心，主要承担设备、用户信息记录和管理，媒体视频数据转发，信令处理和转发;客户端是监控系统的数据接收端，本文指的就是PC端的客户端，主要向服务器发出视频请求和视频数据接收和解码播放。

网络视频前端硬件由DVEVM(Digital Video Evaluation Module)、CCD摄像头和AD芯片组成。其中DVEVM硬件资源包括DDR2 SDRAM、NAND FLASH、串口、网口等，核心是DM365，它是TI公司推出的一款基于达芬奇技术的高性能双核处理器，包括一个主频300MHz的ARM926EJ－S精简指令集处理器和一个支持H.264高清编解码的视频图像协处理器［3］。CCD摄像头选用PAL制式摄像头，用来采集模拟视频数据;TVP5146是一块高质量的AD转换芯片，它支持PAL制式的模拟视频数据转化为20_bit 4:2:2 YCbCr。

系统中主要有两种数据流:信令控制流和视频数据流。信令控制流，即SIP信令流，注册用户就可以在客户端使用SIP信令向服务器请求某一个注册视频前端的视频数据，服务器接到请求后会向该视频前端发出SIP信令用于视频请求，视频前端解析接收的SIP信令，并进行相应的操作。视频前端通过CCD摄像头采集到模拟视频数据流，经过A/D解码芯片转换，由DM365压缩编码为H.264视频流，打包成RTP流发送到服务器实现视频的实时传输。

图1 系统结构图

2 网络视频前端软件结构与实现

网络视频前端基于达芬奇硬件平台和MontaVista Linux嵌入式操作系统，软件结构分为引导层、内核层和应用层。引导层包括UBOOT和UBL，用来初始化和引导内核映像。内核层包括内核映像和文件系统，其中主要包括了初始化内核和设备驱动、挂载文件系统。应用层是软件部分的主体，需要设计和实现视频采集、编码，视频传输和信令控制功能。

2.1 视频采集、视频编码的实现

(1)视频采集，Linux操作系统为所有的视频捕获设备提供了一个统一的驱动程序接口，即V4L2 APIs，通过调用ioctl函数操作视频设备，实现视频采集，DM365的视频处理前端(VPFE)就是基于V4L2接口实现的。视频前端CCD摄像头输出PAL制式基带信号，通过TVP5146进行模数转换处理，输出YCbCr 4:2:2格式数字视频信号，最后DM365的VPFE再对视频信号进行可选的预处理操作，并调用mmap将视频数据的缓存地址提供给应用程序，完成视频采集。

(2)视频编码，视频编解码需要用到达芬奇软件框架的Codec Engine(编解码引擎)技术来实现。Codec Engine定义了一组 VISA(Video，Image，Speech，Audio)APIs供应用程序调用。DM365的高清视频协处理器(HDVICP)侧封装了相应的编解码算法，ARM侧应用程序可以通过VISA APIs进行调用。ARM负责应用程序执行，视频协处理器负责编解码算法执行，降低了ARM资源占用率，提高了编解码的效率。本文采用H.264标准编码，需要调用相应的H.264算法实例。选用TI官方提供的H.264 Baseline Profile编码器的Demo包，其中包含了已经编译好的H.264 Codec算法实例，可以使用Codec Engine APIs来操作Engine实例以及H.264 Codec实例，实现视频编码。

图2 视频采集、编码同步实现

(3)视频采集、编码同步实现，如图2所示。视频采集编码程序由Capture线程、Video线程和Send线程3个线程组成，需要解决各线程之间同步问题和与视频传输进程的进程间通信问题。本文采用条件变量与互斥量实现3个线程之间的同步，3个线程间数据通信采用管道方式;采用信号量与共享内存机制实现与视频传输进程间通信。当各线程初始化完成后，进入主循环。Capture线程负责从采集设备采集原始视频数据，然后通过管道将视频数据发送给Video线程;Video线程用Codec Engine提供的VISA APIs调用协处理器端的H.264编码算法实例进行视频编码，将编码后的视频数据发送给Send线程;Send线程从管道读取编码后的视频帧，写入共享内存，等待视频传输进程来读取。从而完成视频的实时采集与编码。

TI在MontaVista Linux和Codec Engine之上实现了功能层DMAI(达芬奇多媒体应用接口)。DMAI提供功能模块的抽象，封装了本文涉及的底层视频采集模块和编码模块。本文采集编码程序就是调用相应的DMAI接口实现的。

2.2 视频传输的实现

当视频前端应用层收到由服务器转发的视频请求指令，视频传输进程读取共享内存中的NAL单元，打包发送到服务器，本系统采用RTP协议实现网络传输。RTP((Real-time Transport Protocol，实时传输协议)是一种针对多媒体数据流的实时传输协议，其目的是提供时间信息和实现流同步［4］。

根据RFC3984对NAL单元进行RTP打包，使用UDP/IP协议发送到服务器。因为IP协议定义了最大传输单元(MTU)为1500，超过MTU时就会进行自动分片发送，这样会造成解码错误。所以本文规定当NAL单元长度小于MTU时，对单一NAL单元RTP打包，当NAL单元长度超过MTU时，对NAL单元进行分片处理再RTP打包，并且规定 MTU为1 000 Bytes。RTP打包流程图如图3所示，用RTP包头中的序号标志位区别每个RTP包顺序，时间戳标记每个RTP包来区别是否为分片包，规定同一个NAL单元的所有RTP分片包使用相同时间戳，并把时间戳的值设为当前系统时钟。这样，接收端可以根据RTP包头序列号和时间戳来还原视频流顺序。

图3 RTP打包流程图

2.3 控制信令的实现

视频前端应用层接收服务器转发的控制信令，做出相应操作，本文采用会话初始化协议(Session Initiation Protocol，SIP)消息作为通信系统中控制信令的消息载体。SIP是一种用于多媒体系统的控制信令协议，主要用于IP网络上进行多媒体通信时作为控制信令，方便任何应用接入到IP网络［5］。

视频前端SIP信令的实现主要包括设备在服务器的注册，接收服务器转发的视频控制信令，流程如图4所示。本文采用RFC3261中定义的请求方法REGISTER对设备进行注册登记，注册成功后，设备还需要定时向服务器发送心跳包来说明自己仍在线。

服务器转发客户端SIP视频请求信令，视频前端解析信令后，建立多媒体会话。视频前端RTP模块把RTP视频流发送到服务器，再由服务器转发给客户端，完成一次多媒体会话。经过SIP协议和服务器，就可以实现视频前端和客户端之间的数据通信。

图4 SIP信令流程图

3 测试结果

经测试NAL单元I帧大于7000Bytes，P帧大于1000Bytes，使用了RTP分包机制。将视频前端注册到服务器后，通过对应解码播放客户端向服务器发出视频请求，可以在播放器界面看到流畅的D1(720×576)分辨率的实时视频，如图5所示。并且在捕捉图像不断移动的情况下，ARM资源占有率不超过30%。

4 结束语

本文实现了基于DM365硬件平台的网络视频监控系统视频前端。视频前端不仅仅是数据采集终端，而且集成了编码、网络传输和信令控制的核心处理功能，提高了视频前端的系统兼容性。而且应用DM365的ARM+DSP双核模式，增加了传输效率。通过测试发现，实时图像清晰流畅，ARM资源占有率低，可扩展性大，满足系统实时性和稳定性的要求。