基于嵌入式前端服务器的音视频监控系统设计

张纪宽， 彭 力 ， 陈志勇

(江南大学 物联网工程学院，江苏 无锡214122)

普通的网络视频监控系统流程是前端设备采集视频，经特定服务器转发，客户端接收视频数据［1-3］。随着嵌入式技术的成熟，嵌入式前端设备完全拥有充当服务器的能力。如果省略中间环节，直接把服务器部署在采集视频的前端设备上，不仅节约成本而且增强实时性。而随着智能手机等PDA 用户的持续增多，城市无线WiFi 覆盖域的扩大，普通的网络视频监控系统已经无法满足用户在任何时间、任何地点观看监控信息的需求［4］。因此，文中设计并实现了一个以DaVinci 架构DM365 处理器为前端服务器的监控系统，客户端可工作在PC 或者Android 系统的可移动设备上，实现了实时音视频监控。

1 监控系统总体设计

文中实现的系统主要由前端服务器，无线WiFi模块和客户端组成。系统前端服务器采用TMS320DM365 多媒体处理器，对摄像头采集的音视频数据分别进行H.264 和g711 编码，RTP 封包，通过管道给live555 流媒体服务器等待转发;WiFi 模块采用基于IEEE802.11b 的无线协议;同时采用RTP/RTCP，RTSP 协议为客户端提供实时音视频流。客户直接向前端服务器发送请求，接收音视频流，进行同步处理后解码播放;客户端可工作在PC或者Android 可移动设备平台，采用开源的VLC 播放器实现音视频同步播放。系统总体结构如图1所示。

图1 监控系统总体结构Fig.1 Structure of the monitoring system

2 监控系统硬件开发平台

系统硬件平台以Techvdm365 开发板为核心，采用TMS320DM365 处理器。DM365 是TI 推出的基于DaVinci 技术的新一代ARM+DSP 双核架构的视频处理器。支持H.264，MPEG-4，JPEG 等编解码器，灵活性好，使用简单，操作方便［5］。音视频信号处理可以分为两个层次:信号处理层(SPL)和应用程序处理层(APL)。SPL 对应着DSP 核，主要完成音视频的压缩编码;APL 对应着ARM 核，将SPL 各个硬件编解码器抽象为Codec Engine 对象，并把对音视频的相关操作封装为API 函数DMAI，方便完成音视频的处理［6］。开发板硬件资源包括512 MBytes NAND Flash 存储器，128 MBytes DDR2，533 MHz SDRAM，10 M/100 Mb/s 网卡，EMAC，SD/MMC 接口，UART 接口［7］。无线模块使用USR-WIFI232-X WIFI 模块。系统硬件结构见图2。

图2 系统硬件结构Fig.2 Structure of hardware

3 前端服务器软件设计

监控系统软件分为3 个模块:音视频信号处理模块、音视频数据打包模块、流媒体服务器转发模块。音视频信号处理模块主要负责音视频数据的采集、压缩编码、本地存储、本地显示并将处理好的音视频数据流存放指针传给打包模块;音视频打包模块获得数据流后进行RTP 打包，并将打包后的数据存放指针赋给流媒体服务器转发模块;当流媒体服务器转发模块接收到客户端的请求即可将打包好的数据转发给客户端。系统上电后流媒体服务器转发模块始终监听客户端连接请求，信号处理模块将音视频数据存为本地文件，当有客户端连接请求后数据打包模块才会工作。

3.1 基于DVSDK 的音视频信号处理

数字视频软件开发套件(DVSDK)是TI 推出的C 语言软件开发包，功能上可划分为编解码引擎(CE)、应用程序接口(DMAI)、编解码框架组件(FC)、数字视频测试平台(DVTB)、算法标准(xDAIS)［8］。

利用DVSDK 软件开发包开发音视频信号处理程序只需在应用程序层(APL)调用应用程序接口便可操作信号处理层(SPL)对视频图像的压缩编码。音视频信号处理程序分为Capture，Video，Display，Write，Speech 5 个线程，共同完成数据的采集、编码、存储、显示。线程工作流程如图3 所示。

图3 线程工作流程Fig.3 Flowchart of thread

3.2 基于RTP 的H.264 视频流打包算法

H.264 每个NALU 单元由起始码(Start Code)，NALU 头(NALU Header)，原始字节序列(NALU Payload)3 部分依次组成。利用Start Code 标识一个NALU 单元，一般为数值1，占用3 个或者4 个字节;NALU Header 用以说明NALU 单元类型，共1 Byte;NALU Payload 为原始字节序列负荷(RBSP)。NALU 单元格式如图4 所示。

图4 单个NALU 单元格式Fig.4 Single cell form of NALU

使用RTP 协议进行流媒体传输，需要把H.264格式视频数据封装成一系列RTP 数据包。由于网络接收最大数据包为1 500 Bytes，且RTP 协议承载于UDP 协议传输，还需要加上UDP，IP 头约52 Bytes，因此文中使用了一种高效灵活的视频流打包算法。当NALU 单元长度小于1 400 Byte 时采用单一NALU 单元封包模式;当NALU 单元长度大于1 400 Byte 时采用分片封装模式。分片封装模式时RTP 数据格式为［FU idicator］［FU Header］［Payload］［9］。利用FU Header 区分当前包是NALU 分割片的第几片，使接收端能够正确地重新组合一个NALU 单元。音视频数据处理模块的video 线程把编码后的数据存放到内存缓冲区中，在每次打包前需要先判断此缓冲区中有几个NALU 单元，然后根据NALU 单元的大小选择不同的RTP 封包模式。具体程序流程如图5 所示。

图5 视频打包程序流程Fig.5 Flowchart of video package

3.3 基于live555 的RTSP 服务器构建

流媒体数据转发服务器模块主要作用是监听客户端的连接请求，实现RTSP 监听。该模块工作在阻塞模式，一旦获得客户端的IP 和端口，就会创建RTP 会话，并向数据打包模块发送RTP 数据请求，促使其对信号处理模块缓冲区中的数据进行RTP打包，并把数据转发给客户端。服务器主要流程如图6 所示。

图6 服务器程序流程Fig.6 Flowchart of server program

文中通过移植live555 到前端设备DM365 中实现RTSP 流媒体服务器。live555 是一个为流媒体提供解决方案的跨平台C ++ 开源项目，完成对标准媒体 传 输 协 议RTP/RTCP，RTSP 等 的 支 持［10］。Live555 整体框架主要包括4 个重要模块:UsageEnvironment 模块对系统环境的抽象，包括抽象 类 UsageEnvironment 和 TaskScheduler;Basic UsageEnvironment 模块是UsageEnvironment 的一个控制台应用的实现，即针对控制台的输入输出和信号响应进行具体实现;GroupSock 模块用于实现数据包的发送和接收;LiveMedia 模块是Live555 最重要的模块， 包括如下派生类:RTSPClient，MediaSession，RTCPInstance，Source 和Sink。类图结构如图7 所示。

4 客户端设计

客户端主要负责接收流媒体数据并进行解码播放，由于监控系统实现的是音视频监控，需要对接收到的音视频数据进行同步处理。关于音视频同步标准参考文献［11］，同步算法参考文献［1］。

RTP_video 和NTP_video 分别为视频会话的RTP 和NTP 时间戳，RTP_audio 和NTP_audio 分别为音频会话的RTP 和NTP 时间戳，Clock 为媒体的时钟频率。

在NTP_audio 时刻，视频的RTP 时间戳应为

RTP_video_audiotime = RTP_video +

设当前时刻视频和音频的RTP 时间戳分别为:RTP_video_cur，RTP_audio_cur，如果媒体间保持同步，必须满足下式:

设实际收到视频的RTP 时间戳为RTP_video_real，音视频可通过下式判断是否同步:

其中，T = 80 ms/Clock_audio。

同步程序流程如图8 所示。

图7 live555 类图结构Fig.7 Structure of live 555

图8 音视频同步程序流程Fig.8 Flowchart of audio and video synchronization program

5 监控系统测试

文中已实现监控系统所有模块，前端服务器IP地址为172.18.168.63，RTP 音视频会话端口分别为9 000 和8 000。分别在PC 端和Android 手机端测试如下:

先运行前端服务器，串口调试助手显示"We use port 8550 for optional RTSP tunneling"，在Android 端运行VLC，打开网络，输入:RTSP://172.18.168.63:8550/，点击播放。音视频实时性良好，音视频同步效果良好，VLC 显示如图9 所示。

图9 Android 和PC 端显示Fig.9 Display of android and PC

VLC 播放器可以查看播放音视频的统计信息，如图10 所示。从图10 的数据可以看出，音视频串流码率可达523 kb/s，此时丢包率分别为3/17 259 =0.017%，5/8 482 = 0.059%，对监控系统不造成任何影响。由于传输的都是经过编码压缩后的音视频数据流，大大降低了网络压力。由于音频数据量小于视频，每包为固定的160 Byte，不需重新合成，因此解码的帧数大于视频帧。收到视频帧后要经过重新合成NALU 后再解码播放，而且同步时以音频为主线，因此显示的帧要多于解码的帧，证明有一部分帧由于视频超前被重复播放。前端服务器是边采集边打包发送的，减小了接收端同步程序的压力，多次测试未出现由于无法同步而重新申请服务器的现象。

6 结 语

文中提出了一种基于嵌入式前端服务器的音视频监控系统，直接利用前端设备作为服务器，提高实时性，节约成本。利用嵌入式多媒体处理器DM365，开源的live555 和H.264 高性能视频编解码技术，实现了音视频的实时监控。该技术为后续前端设备直接对采集的视频进行算法处理实现智能监控打下了基础。

图10 VLC 统计信息Fig.10 Statisticsl of VLC

［1］刘君亮.基于TMS320DM365 的音视频传输及智能视频分析系统的设计与实现［D］. 南京:南京邮电大学，2012:4-5，56-58.

［2］周司.基于TCP 传输的嵌入式流媒体播放系统［D］.南京:南京理工大学，2014:15-16.

［3］惠晓威，王克.移动视频监控系统的实现［J］.计算机应用与软件，2014，31(1):148-150.

HUI Xiaowei，WANG Ke.Realisation of mobile video surveillance system［J］.Computer Applications and Software，2014，31(1):148-150.(in Chinese)

［4］张雅楠，杨璐，郑丽敏.基于Android 手机的远程视频监控系统的设计与开发［J］.计算机应用，2013，33(S1):283-286.

ZHANG Yanan，YANG Lu，ZHENG Limin.Remote video surveillance system based on Android mobile phone［J］.2013，33(S1):283-286.(in Chinese)

［5］Texas Instruments Incorporated. TMS320DM36x Digital Media System-on-chip (DMSoC)ARM Subsystem Users Guide［M］.Dallas，Texas:Texas Instruments Incorporated，2009.

［6］Texas Instruments Incorporated. Davinci Multimedia Application Interface (DMAI)User Guide［M］. Dallas，Texas:Texas Instruments Incorporated，2009.

［7］Deepu Talla，Jeremiab Golston. Using DaVinci technology for digital video device［J］. IEEE Computer Socity，2007，40(10):63-61.

［8］Texas Instruments Incorporated.Codec Engine Application Developer＇s Guide［M］.Dallas，Texas:Texas Instruments Incorporated，2009.

［9］李校林，刘利权，张杰.基于RTP 的H.264 视频流实时打包传输的研究［J］.计算机工程与科学，2012，34(5):168-171.

LI Xiaolin，LIU Liquan，ZHANG Jie.Research on the H.264 real-time video＇s packaged transport based on RTP［J］. Computer Engineering and Science，2012，34(5):168-171.(in Chinese)

［10］刘畅棂，包杰，王宁国.基于Live555 的网络视频监控系统设计与实现［J］.现代电信科技，2012，42(12):38-42.

LIU Changlin，BAO Jie，WANG Ninggou. Design and implement of network video monitoring system based on Live555［J］.Modern Science and Technology of Telecommunications，2012，42(12):38-42.(in Chinese)

［11］王风纯，鲁静.基于RTP/RTCP 的音视频同步方法研究［J］.软件，2011，32(6):78-80.

WANG Fengchun，LU Jing. A method of audio and video synchronization control based on RTP/RTCP［J］. Software，2011，32(6):78-80.(in Chinese)