張紀(jì)寬， 彭 力 ， 陳志勇

(江南大學(xué) 物聯(lián)網(wǎng)工程學(xué)院，江蘇 無(wú)錫214122)

普通的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)流程是前端設(shè)備采集視頻，經(jīng)特定服務(wù)器轉(zhuǎn)發(fā)，客戶端接收視頻數(shù)據(jù)［1-3］。隨著嵌入式技術(shù)的成熟，嵌入式前端設(shè)備完全擁有充當(dāng)服務(wù)器的能力。如果省略中間環(huán)節(jié)，直接把服務(wù)器部署在采集視頻的前端設(shè)備上，不僅節(jié)約成本而且增強(qiáng)實(shí)時(shí)性。而隨著智能手機(jī)等PDA 用戶的持續(xù)增多，城市無(wú)線WiFi 覆蓋域的擴(kuò)大，普通的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)已經(jīng)無(wú)法滿足用戶在任何時(shí)間、任何地點(diǎn)觀看監(jiān)控信息的需求［4］。因此，文中設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)以DaVinci 架構(gòu)DM365 處理器為前端服務(wù)器的監(jiān)控系統(tǒng)，客戶端可工作在PC 或者Android 系統(tǒng)的可移動(dòng)設(shè)備上，實(shí)現(xiàn)了實(shí)時(shí)音視頻監(jiān)控。

1 監(jiān)控系統(tǒng)總體設(shè)計(jì)

文中實(shí)現(xiàn)的系統(tǒng)主要由前端服務(wù)器，無(wú)線WiFi模塊和客戶端組成。系統(tǒng)前端服務(wù)器采用TMS320DM365 多媒體處理器，對(duì)攝像頭采集的音視頻數(shù)據(jù)分別進(jìn)行H.264 和g711 編碼，RTP 封包，通過(guò)管道給live555 流媒體服務(wù)器等待轉(zhuǎn)發(fā);WiFi 模塊采用基于IEEE802.11b 的無(wú)線協(xié)議;同時(shí)采用RTP/RTCP，RTSP 協(xié)議為客戶端提供實(shí)時(shí)音視頻流?？蛻糁苯酉蚯岸朔?wù)器發(fā)送請(qǐng)求，接收音視頻流，進(jìn)行同步處理后解碼播放;客戶端可工作在PC或者Android 可移動(dòng)設(shè)備平臺(tái)，采用開(kāi)源的VLC 播放器實(shí)現(xiàn)音視頻同步播放。系統(tǒng)總體結(jié)構(gòu)如圖1所示。

圖1 監(jiān)控系統(tǒng)總體結(jié)構(gòu)Fig.1 Structure of the monitoring system

2 監(jiān)控系統(tǒng)硬件開(kāi)發(fā)平臺(tái)

系統(tǒng)硬件平臺(tái)以Techvdm365 開(kāi)發(fā)板為核心，采用TMS320DM365 處理器。DM365 是TI 推出的基于DaVinci 技術(shù)的新一代ARM+DSP 雙核架構(gòu)的視頻處理器。支持H.264，MPEG-4，JPEG 等編解碼器，靈活性好，使用簡(jiǎn)單，操作方便［5］。音視頻信號(hào)處理可以分為兩個(gè)層次:信號(hào)處理層(SPL)和應(yīng)用程序處理層(APL)。SPL 對(duì)應(yīng)著DSP 核，主要完成音視頻的壓縮編碼;APL 對(duì)應(yīng)著ARM 核，將SPL 各個(gè)硬件編解碼器抽象為Codec Engine 對(duì)象，并把對(duì)音視頻的相關(guān)操作封裝為API 函數(shù)DMAI，方便完成音視頻的處理［6］。開(kāi)發(fā)板硬件資源包括512 MBytes NAND Flash 存儲(chǔ)器，128 MBytes DDR2，533 MHz SDRAM，10 M/100 Mb/s 網(wǎng)卡，EMAC，SD/MMC 接口，UART 接口［7］。無(wú)線模塊使用USR-WIFI232-X WIFI 模塊。系統(tǒng)硬件結(jié)構(gòu)見(jiàn)圖2。

圖2 系統(tǒng)硬件結(jié)構(gòu)Fig.2 Structure of hardware

3 前端服務(wù)器軟件設(shè)計(jì)

監(jiān)控系統(tǒng)軟件分為3 個(gè)模塊:音視頻信號(hào)處理模塊、音視頻數(shù)據(jù)打包模塊、流媒體服務(wù)器轉(zhuǎn)發(fā)模塊。音視頻信號(hào)處理模塊主要負(fù)責(zé)音視頻數(shù)據(jù)的采集、壓縮編碼、本地存儲(chǔ)、本地顯示并將處理好的音視頻數(shù)據(jù)流存放指針傳給打包模塊;音視頻打包模塊獲得數(shù)據(jù)流后進(jìn)行RTP 打包，并將打包后的數(shù)據(jù)存放指針賦給流媒體服務(wù)器轉(zhuǎn)發(fā)模塊;當(dāng)流媒體服務(wù)器轉(zhuǎn)發(fā)模塊接收到客戶端的請(qǐng)求即可將打包好的數(shù)據(jù)轉(zhuǎn)發(fā)給客戶端。系統(tǒng)上電后流媒體服務(wù)器轉(zhuǎn)發(fā)模塊始終監(jiān)聽(tīng)客戶端連接請(qǐng)求，信號(hào)處理模塊將音視頻數(shù)據(jù)存為本地文件，當(dāng)有客戶端連接請(qǐng)求后數(shù)據(jù)打包模塊才會(huì)工作。

3.1 基于DVSDK 的音視頻信號(hào)處理

數(shù)字視頻軟件開(kāi)發(fā)套件(DVSDK)是TI 推出的C 語(yǔ)言軟件開(kāi)發(fā)包，功能上可劃分為編解碼引擎(CE)、應(yīng)用程序接口(DMAI)、編解碼框架組件(FC)、數(shù)字視頻測(cè)試平臺(tái)(DVTB)、算法標(biāo)準(zhǔn)(xDAIS)［8］。

利用DVSDK 軟件開(kāi)發(fā)包開(kāi)發(fā)音視頻信號(hào)處理程序只需在應(yīng)用程序?qū)?APL)調(diào)用應(yīng)用程序接口便可操作信號(hào)處理層(SPL)對(duì)視頻圖像的壓縮編碼。音視頻信號(hào)處理程序分為Capture，Video，Display，Write，Speech 5 個(gè)線程，共同完成數(shù)據(jù)的采集、編碼、存儲(chǔ)、顯示。線程工作流程如圖3 所示。

圖3 線程工作流程Fig.3 Flowchart of thread

3.2 基于RTP 的H.264 視頻流打包算法

H.264 每個(gè)NALU 單元由起始碼(Start Code)，NALU 頭(NALU Header)，原始字節(jié)序列(NALU Payload)3 部分依次組成。利用Start Code 標(biāo)識(shí)一個(gè)NALU 單元，一般為數(shù)值1，占用3 個(gè)或者4 個(gè)字節(jié);NALU Header 用以說(shuō)明NALU 單元類型，共1 Byte;NALU Payload 為原始字節(jié)序列負(fù)荷(RBSP)。NALU 單元格式如圖4 所示。

圖4 單個(gè)NALU 單元格式Fig.4 Single cell form of NALU

使用RTP 協(xié)議進(jìn)行流媒體傳輸，需要把H.264格式視頻數(shù)據(jù)封裝成一系列RTP 數(shù)據(jù)包。由于網(wǎng)絡(luò)接收最大數(shù)據(jù)包為1 500 Bytes，且RTP 協(xié)議承載于UDP 協(xié)議傳輸，還需要加上UDP，IP 頭約52 Bytes，因此文中使用了一種高效靈活的視頻流打包算法。當(dāng)NALU 單元長(zhǎng)度小于1 400 Byte 時(shí)采用單一NALU 單元封包模式;當(dāng)NALU 單元長(zhǎng)度大于1 400 Byte 時(shí)采用分片封裝模式。分片封裝模式時(shí)RTP 數(shù)據(jù)格式為［FU idicator］［FU Header］［Payload］［9］。利用FU Header 區(qū)分當(dāng)前包是NALU 分割片的第幾片，使接收端能夠正確地重新組合一個(gè)NALU 單元。音視頻數(shù)據(jù)處理模塊的video 線程把編碼后的數(shù)據(jù)存放到內(nèi)存緩沖區(qū)中，在每次打包前需要先判斷此緩沖區(qū)中有幾個(gè)NALU 單元，然后根據(jù)NALU 單元的大小選擇不同的RTP 封包模式。具體程序流程如圖5 所示。

圖5 視頻打包程序流程Fig.5 Flowchart of video package

3.3 基于live555 的RTSP 服務(wù)器構(gòu)建

流媒體數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器模塊主要作用是監(jiān)聽(tīng)客戶端的連接請(qǐng)求，實(shí)現(xiàn)RTSP 監(jiān)聽(tīng)。該模塊工作在阻塞模式，一旦獲得客戶端的IP 和端口，就會(huì)創(chuàng)建RTP 會(huì)話，并向數(shù)據(jù)打包模塊發(fā)送RTP 數(shù)據(jù)請(qǐng)求，促使其對(duì)信號(hào)處理模塊緩沖區(qū)中的數(shù)據(jù)進(jìn)行RTP打包，并把數(shù)據(jù)轉(zhuǎn)發(fā)給客戶端。服務(wù)器主要流程如圖6 所示。

圖6 服務(wù)器程序流程Fig.6 Flowchart of server program

文中通過(guò)移植live555 到前端設(shè)備DM365 中實(shí)現(xiàn)RTSP 流媒體服務(wù)器。live555 是一個(gè)為流媒體提供解決方案的跨平臺(tái)C ++ 開(kāi)源項(xiàng)目，完成對(duì)標(biāo)準(zhǔn)媒體 傳 輸 協(xié) 議RTP/RTCP，RTSP 等 的 支 持［10］。Live555 整體框架主要包括4 個(gè)重要模塊:UsageEnvironment 模塊對(duì)系統(tǒng)環(huán)境的抽象，包括抽象 類 UsageEnvironment 和 TaskScheduler;Basic UsageEnvironment 模塊是UsageEnvironment 的一個(gè)控制臺(tái)應(yīng)用的實(shí)現(xiàn)，即針對(duì)控制臺(tái)的輸入輸出和信號(hào)響應(yīng)進(jìn)行具體實(shí)現(xiàn);GroupSock 模塊用于實(shí)現(xiàn)數(shù)據(jù)包的發(fā)送和接收;LiveMedia 模塊是Live555 最重要的模塊， 包括如下派生類:RTSPClient，MediaSession，RTCPInstance，Source 和Sink。類圖結(jié)構(gòu)如圖7 所示。

4 客戶端設(shè)計(jì)

客戶端主要負(fù)責(zé)接收流媒體數(shù)據(jù)并進(jìn)行解碼播放，由于監(jiān)控系統(tǒng)實(shí)現(xiàn)的是音視頻監(jiān)控，需要對(duì)接收到的音視頻數(shù)據(jù)進(jìn)行同步處理。關(guān)于音視頻同步標(biāo)準(zhǔn)參考文獻(xiàn)［11］，同步算法參考文獻(xiàn)［1］。

RTP_video 和NTP_video 分別為視頻會(huì)話的RTP 和NTP 時(shí)間戳，RTP_audio 和NTP_audio 分別為音頻會(huì)話的RTP 和NTP 時(shí)間戳，Clock 為媒體的時(shí)鐘頻率。

在NTP_audio 時(shí)刻，視頻的RTP 時(shí)間戳應(yīng)為

RTP_video_audiotime = RTP_video +

設(shè)當(dāng)前時(shí)刻視頻和音頻的RTP 時(shí)間戳分別為:RTP_video_cur，RTP_audio_cur，如果媒體間保持同步，必須滿足下式:

設(shè)實(shí)際收到視頻的RTP 時(shí)間戳為RTP_video_real，音視頻可通過(guò)下式判斷是否同步:

其中，T = 80 ms/Clock_audio。

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

圖7 live555 類圖結(jié)構(gòu)Fig.7 Structure of live 555

圖8 音視頻同步程序流程Fig.8 Flowchart of audio and video synchronization program

5 監(jiān)控系統(tǒng)測(cè)試

文中已實(shí)現(xiàn)監(jiān)控系統(tǒng)所有模塊，前端服務(wù)器IP地址為172.18.168.63，RTP 音視頻會(huì)話端口分別為9 000 和8 000。分別在PC 端和Android 手機(jī)端測(cè)試如下:

先運(yùn)行前端服務(wù)器，串口調(diào)試助手顯示"We use port 8550 for optional RTSP tunneling"，在Android 端運(yùn)行VLC，打開(kāi)網(wǎng)絡(luò)，輸入:RTSP://172.18.168.63:8550/，點(diǎn)擊播放。音視頻實(shí)時(shí)性良好，音視頻同步效果良好，VLC 顯示如圖9 所示。

圖9 Android 和PC 端顯示Fig.9 Display of android and PC

VLC 播放器可以查看播放音視頻的統(tǒng)計(jì)信息，如圖10 所示。從圖10 的數(shù)據(jù)可以看出，音視頻串流碼率可達(dá)523 kb/s，此時(shí)丟包率分別為3/17 259 =0.017%，5/8 482 = 0.059%，對(duì)監(jiān)控系統(tǒng)不造成任何影響。由于傳輸?shù)亩际墙?jīng)過(guò)編碼壓縮后的音視頻數(shù)據(jù)流，大大降低了網(wǎng)絡(luò)壓力。由于音頻數(shù)據(jù)量小于視頻，每包為固定的160 Byte，不需重新合成，因此解碼的幀數(shù)大于視頻幀。收到視頻幀后要經(jīng)過(guò)重新合成NALU 后再解碼播放，而且同步時(shí)以音頻為主線，因此顯示的幀要多于解碼的幀，證明有一部分幀由于視頻超前被重復(fù)播放。前端服務(wù)器是邊采集邊打包發(fā)送的，減小了接收端同步程序的壓力，多次測(cè)試未出現(xiàn)由于無(wú)法同步而重新申請(qǐng)服務(wù)器的現(xiàn)象。

6 結(jié) 語(yǔ)

文中提出了一種基于嵌入式前端服務(wù)器的音視頻監(jiān)控系統(tǒng)，直接利用前端設(shè)備作為服務(wù)器，提高實(shí)時(shí)性，節(jié)約成本。利用嵌入式多媒體處理器DM365，開(kāi)源的live555 和H.264 高性能視頻編解碼技術(shù)，實(shí)現(xiàn)了音視頻的實(shí)時(shí)監(jiān)控。該技術(shù)為后續(xù)前端設(shè)備直接對(duì)采集的視頻進(jìn)行算法處理實(shí)現(xiàn)智能監(jiān)控打下了基礎(chǔ)。

圖10 VLC 統(tǒng)計(jì)信息Fig.10 Statisticsl of VLC

［1］劉君亮.基于TMS320DM365 的音視頻傳輸及智能視頻分析系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)［D］. 南京:南京郵電大學(xué)，2012:4-5，56-58.

［2］周司.基于TCP 傳輸?shù)那度胧搅髅襟w播放系統(tǒng)［D］.南京:南京理工大學(xué)，2014:15-16.

［3］惠曉威，王克.移動(dòng)視頻監(jiān)控系統(tǒng)的實(shí)現(xiàn)［J］.計(jì)算機(jī)應(yīng)用與軟件，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ī)的遠(yuǎn)程視頻監(jiān)控系統(tǒng)的設(shè)計(jì)與開(kāi)發(fā)［J］.計(jì)算機(jī)應(yīng)用，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］李校林，劉利權(quán)，張杰.基于RTP 的H.264 視頻流實(shí)時(shí)打包傳輸?shù)难芯浚跩］.計(jì)算機(jī)工程與科學(xué)，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］劉暢欞，包杰，王寧國(guó).基于Live555 的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)［J］.現(xiàn)代電信科技，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］王風(fēng)純，魯靜.基于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)