基于DM365網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的設(shè)計與實(shí)現(xiàn)

摘 要： 采用DM365達(dá)芬奇視頻處理芯片開發(fā)了嵌入式網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)，選擇H.264視頻數(shù)據(jù)編碼算法以提高數(shù)據(jù)編碼效率。該系統(tǒng)軟件包括視頻監(jiān)控服務(wù)器模塊和客戶監(jiān)控端模塊。運(yùn)行于DM365平臺上的視頻監(jiān)控服務(wù)器將采集的視頻數(shù)據(jù)經(jīng)過H.264編碼器壓縮后存儲在硬盤上，并以RTP/RTCP協(xié)議傳輸給客戶監(jiān)控端；運(yùn)行于PC機(jī)上的客戶監(jiān)控端程序可以實(shí)現(xiàn)攝像頭的遠(yuǎn)程控制與實(shí)時監(jiān)控現(xiàn)場。

關(guān)鍵詞： DM365； 視頻監(jiān)控系統(tǒng)； H.264； 流媒體

中圖分類號：TP393.07 文獻(xiàn)標(biāo)志碼：A 文章編號：1006-8228（2013）10-35-03

0 引言

隨著電子、計算機(jī)、通信和自動化技術(shù)的發(fā)展，嵌入式視頻監(jiān)控系統(tǒng)已成為現(xiàn)代安防系統(tǒng)發(fā)展趨勢，并且已經(jīng)引起了人們的重視。嵌入式視頻監(jiān)控系統(tǒng)主要由嵌入式處理器、嵌入式操作系統(tǒng)及相關(guān)軟硬件等組成。TI公司的達(dá)芬奇技術(shù)是一種專門針對數(shù)字視頻應(yīng)用、基于信號處理的解決方案，能為視頻設(shè)備制造商提供集成處理器、軟件、工具和支持，以簡化設(shè)計進(jìn)程，加速產(chǎn)品創(chuàng)新[1]。本系統(tǒng)采用TM320DM365（簡稱DM365）視頻處理芯片開發(fā)嵌入式網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)，它具有功耗低、性能高、開發(fā)周期短、可擴(kuò)展等優(yōu)點(diǎn)。

1 網(wǎng)絡(luò)視頻監(jiān)視系統(tǒng)結(jié)構(gòu)

DM365處理器集成了一個ARM926EJ-S內(nèi)核，一個H.264高清編解碼協(xié)處理器HDVICP和一個MPEG-4/JPEG高清編解碼協(xié)處理器MJCP，可以支持H.264/MPEG-4高清視頻編解碼。本系統(tǒng)利用DM365的強(qiáng)大運(yùn)算能力，在ARM926EJ-S內(nèi)核上運(yùn)行基于Linux操作系統(tǒng)的應(yīng)用程序?qū)崿F(xiàn)視頻采集、視頻顯示、網(wǎng)絡(luò)通信、流媒體傳輸、外圍器件控制等；在HDVICP協(xié)處理器上運(yùn)行H.264算法來實(shí)現(xiàn)視頻編碼。

本系統(tǒng)所設(shè)計的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)總體結(jié)構(gòu)如圖1所示，它由攝像頭、視頻服務(wù)器、網(wǎng)絡(luò)和客戶監(jiān)控端等模塊組成。攝像頭實(shí)現(xiàn)對現(xiàn)場實(shí)時視頻的采集，由視頻服務(wù)器讀取采集到的視頻信號經(jīng)H.264編碼器編碼后進(jìn)行存儲和網(wǎng)絡(luò)實(shí)時傳輸；客戶監(jiān)控端主要完成視頻信號的接收、存儲、播放和下載等功能。另外，客戶監(jiān)控端可以把用戶的操作轉(zhuǎn)換成相應(yīng)的控制信號發(fā)送到視頻服務(wù)器，由視頻服務(wù)器對外圍器件進(jìn)行控制。

2 視頻監(jiān)控服務(wù)器模塊的設(shè)計

視頻監(jiān)控服務(wù)器的主要任務(wù)是監(jiān)聽網(wǎng)絡(luò)連接，采集視頻數(shù)據(jù)，視頻數(shù)據(jù)壓縮編碼，存儲視頻數(shù)據(jù)并分發(fā)給客戶監(jiān)視端[2]。在視頻數(shù)據(jù)采集方面，使用V4L2常用模型；在編碼方面，結(jié)合DM365芯片的特點(diǎn)采用H.264壓縮編碼標(biāo)準(zhǔn)；另外，使用RTP/RTCP協(xié)議在視頻監(jiān)控服務(wù)器與客戶監(jiān)控端之間進(jìn)行視頻數(shù)據(jù)傳輸[3]。

2.1 視頻監(jiān)視服務(wù)器模塊工作流程

視頻監(jiān)控服務(wù)器包括三個子模塊，一是視頻數(shù)據(jù)處理子模塊，負(fù)責(zé)視頻數(shù)據(jù)采集與編碼；二是視頻監(jiān)控控制子模塊，負(fù)責(zé)開啟、關(guān)閉視頻監(jiān)控等控制操作；三是數(shù)據(jù)傳輸子模塊，負(fù)責(zé)視頻數(shù)據(jù)的實(shí)時傳輸以及備份視頻數(shù)據(jù)等工作。視頻監(jiān)控服務(wù)器模塊的工作流程如下。

① 主控程序?qū)ο到y(tǒng)初始化，主要包括ARM處理器與HDVICP協(xié)處理器的共享內(nèi)存的配置，視頻采集設(shè)備的初始化等。

② 主控程序建立視頻采集線程Capture、視頻壓縮線程Video、視頻數(shù)據(jù)存儲與實(shí)時傳輸線程Trans、視頻文件備份線程BackData和監(jiān)聽線程Listen。當(dāng)主控程序完成初始化工作和線程創(chuàng)建工作后轉(zhuǎn)化為系統(tǒng)控制線程Ctrl。

③ Capture線程負(fù)責(zé)采集視頻信號；Video線程負(fù)責(zé)將視頻采集線程采集到的視頻信號用H.264編碼器壓縮編碼；Trans線程負(fù)責(zé)將壓縮后的視頻數(shù)據(jù)存儲在視頻服務(wù)器端的硬盤上，并實(shí)時地將視頻流傳輸給視頻監(jiān)控端；Listen線程主要負(fù)責(zé)監(jiān)聽客戶監(jiān)控端的控制命令，并對命令進(jìn)行詞法解析，執(zhí)行相應(yīng)的命令；BackData線程負(fù)責(zé)視頻文件的傳輸，以備客戶端備份視頻文件。

④ 如果退出系統(tǒng)，則所有線程結(jié)束；否則循環(huán)執(zhí)行③。

2.2 視頻數(shù)據(jù)處理子模塊流程

在視頻監(jiān)控服務(wù)器中涉及到的數(shù)據(jù)分為兩類：一類是攝像頭采集到的原始視頻數(shù)據(jù)，一類是壓縮后的視頻數(shù)據(jù)。這兩類數(shù)據(jù)均存放在緩沖區(qū)中，這些緩沖區(qū)被多個線程共享。共享的方法是采用管道通信，一方將緩沖區(qū)的地址送入管道，另一方從管道讀取緩沖區(qū)地址對該緩沖區(qū)共享。

2.2.1 緩沖區(qū)共享

由于運(yùn)行在Linux上的應(yīng)用程序調(diào)用malloc獲得的緩沖區(qū)所用地址均為虛擬地址，因此，緩沖區(qū)的物理空間不一定連續(xù)，當(dāng)把緩沖區(qū)的地址傳遞給協(xié)處理器進(jìn)行編碼的時候，數(shù)據(jù)完整性問題就出現(xiàn)了，因?yàn)榫幋a算法是運(yùn)行在HDVICP協(xié)處理器上的，這是一個只有實(shí)地址的世界。所以，TI公司開發(fā)的編碼引擎（Codec Engine，簡稱CE）的軟件架構(gòu)時提供了CMEM模塊，該模塊為ARM926EJ-S內(nèi)核和協(xié)處理器之間通信提供了連續(xù)的內(nèi)存。程序員可調(diào)用CMEM API申請物理上連續(xù)的共享緩沖區(qū)。

本系統(tǒng)設(shè)置了四個管道，其中CVInFifo和CVOutFifo這兩個管道由Capture線程和Video線程共享；VTInFifo和VTOutFifo這兩個管道由Video線程和Trans線程共享。三個線程共享四個管道的示意圖如圖2所示。在系統(tǒng)初始化時，Video線程和Trans線程通過調(diào)用CMEM API分別申請若干個物理地址連續(xù)的緩沖區(qū)，Video線程將其申請的緩沖區(qū)地址送入CVInFifo管道，Trans線程將其申請的緩沖區(qū)送到VTOutFifo管道。Capture、Video、Trans和Ctrl四個線程匯集在一起后，循環(huán)執(zhí)行以下步驟以實(shí)現(xiàn)視頻數(shù)據(jù)的采集、編碼和傳輸。

[Video線程初始化時，申請若干個連續(xù)的緩沖區(qū)，并將各緩沖區(qū)地址送入管道。][⑤Video線程將廢棄的緩沖區(qū)hCapBuf送入管道，供Capture線程使用。][②Capture線程將緩沖區(qū)hCapBuf的地址送入管道。][⑥Video線程將已編碼視頻數(shù)據(jù)緩沖區(qū)hDstBuf的地址送入管道。][⑧Trans線程將廢棄的緩沖區(qū)hDstBuf送入管道供Video線程使用。][Trans線程初始化時，申請若干個連續(xù)的緩沖區(qū)，并將各緩沖區(qū)地址送入管道。][①Capture線程從管道獲取一個空緩沖區(qū)hCapBuf，并采集一幀原始視頻保存在該緩沖區(qū)中。][③Video線程獲得裝有原始視頻幀的緩沖區(qū)hCapBuf。][⑦Trans線程從管道獲取一個已編碼的緩沖區(qū)hDstBuf，將其內(nèi)容寫入文件，并按RTP/RTCP協(xié)議傳輸給客戶端。][④Video線程從管道獲取一個空緩沖區(qū)hDstBuf，并對hCapBuf緩沖區(qū)中的視頻數(shù)據(jù)進(jìn)行編碼，其結(jié)果存放在緩沖區(qū)hDstBuf中。] [CVInfifo] [CVOufifo] [VTInFifo] [VTOutfifo]

① Capture線程從CVInFifo管道獲取一個空緩沖區(qū)hCapBuf，采集一幀視頻并保存在該緩沖區(qū)中；

② Capture線程將緩沖區(qū)hCapBuf地址送入CVOutFifo管道；

③ Video線程從CVOutFifo管道中獲得裝有原始視頻幀的緩沖區(qū)hCapBuf；

④ Video線程從VTOutFifo管道中獲取一個空緩沖區(qū)hDstBuf，并對hCapBuf緩沖區(qū)中的視頻數(shù)據(jù)用H.264編碼器進(jìn)行編碼，其結(jié)果存放在緩沖區(qū)hDstBuf中；

⑤ Video線程將廢棄的緩沖區(qū)hCapBuf送CVInFifo管道，供Capture線程循環(huán)利用；

⑥ Video線程將已編碼的視頻數(shù)據(jù)緩沖區(qū)hDstBuf的地址送入VTInFifo管道；

⑦ Trans線程從管道獲取一個已編碼的緩沖區(qū)hDstBuf，將其內(nèi)容寫入文件，并按RTP/RTCP協(xié)議傳輸給客戶端；

⑧ Trans線程將廢棄的緩沖區(qū)hDstBuf送入管道供Video線程使用。

2.2.2 H.264編碼器

系統(tǒng)選擇先進(jìn)的H.264編碼方案。H.264編碼器繼承了H.263和MPEGl/2/4視頻編碼器的優(yōu)點(diǎn)，在吸收變換編碼和運(yùn)動補(bǔ)償?shù)幕A(chǔ)上，采用全新的幀內(nèi)預(yù)測、多幀參考預(yù)測、高精度運(yùn)動估計、類DCT整數(shù)變換、基于上下文的自適應(yīng)熵編碼、去塊效應(yīng)濾波等編碼技術(shù)，有效提高了數(shù)據(jù)壓縮效率[4]。H.264引入了面向包的編碼機(jī)制，有利于網(wǎng)絡(luò)中的分組傳輸，支持網(wǎng)絡(luò)中視頻的流媒體傳輸，能適應(yīng)于不同網(wǎng)絡(luò)中的視頻傳輸，網(wǎng)絡(luò)親和性好。

在H.264標(biāo)準(zhǔn)中定義了兩個層次：視頻編碼層（VCL）和網(wǎng)絡(luò)抽象層（NAL）。VCL主要負(fù)責(zé)高效的數(shù)字視頻數(shù)據(jù)壓縮。VCL處理的是塊、宏塊和片的數(shù)據(jù)，并盡可能地設(shè)計成不依賴于任何網(wǎng)絡(luò)的特性。NAL處理的主要是片以上的數(shù)據(jù)，提供適當(dāng)?shù)慕涌趯?shù)據(jù)進(jìn)行打包和傳送。在VCL和NAL之間定義了一個基于分組方式的接口。這樣，高編碼效率和網(wǎng)絡(luò)友好性的任務(wù)分別由VCL和NAL來完成。H.264的這種雙結(jié)構(gòu)擴(kuò)大了應(yīng)用范圍，幾乎涵蓋了視頻監(jiān)控、視頻點(diǎn)播、流媒體業(yè)務(wù)等大部分的視頻業(yè)務(wù)。

本系統(tǒng)采用TI達(dá)芬奇技術(shù)來實(shí)現(xiàn)H.264編碼器，此視頻壓縮算法運(yùn)行在HDVICP協(xié)處理器端，ARM端通過引擎Codec Engine和服務(wù)器Code Server與HDVICP協(xié)處理器進(jìn)行交互[5]。編碼后的H.264視頻序列是由一系列NAL單元構(gòu)成。一個NAL單元就是一個變長的包括某一類型的語義元素的字節(jié)流。比如，NAL單元可以裝載一個圖像碼片、一個A/B/C的數(shù)據(jù)分割、一個序列或者圖像的參數(shù)設(shè)置等。

2.3 網(wǎng)絡(luò)傳輸模塊的設(shè)計

網(wǎng)絡(luò)傳輸模塊的主要功能是負(fù)責(zé)為客戶端的請求建立鏈接，并將經(jīng)H.264編碼器編碼的視頻流傳輸給客戶端。這項工作由Listen和Trans兩個線程完成。

網(wǎng)絡(luò)服務(wù)器與客戶監(jiān)控端采用UDP數(shù)據(jù)包進(jìn)行通信。Listen線程循環(huán)監(jiān)聽用戶請求，當(dāng)有用戶請求實(shí)時監(jiān)控視頻時，Listen線程將該用戶的IP地址及UDP端口號保存在與Trans線程共享的變量ClientUdp[]中，Trans線程根據(jù)變量ClientUdp[]創(chuàng)建UDP套接字，并按RTP/RTCP協(xié)議傳輸實(shí)時視頻編碼。當(dāng)用戶關(guān)閉視頻監(jiān)時，Listen同樣將用戶的關(guān)閉視頻請求傳遞給Trans，Trans將關(guān)閉相應(yīng)的UDP套接字，停止視頻的實(shí)時傳輸。另外，Listen線程還具有接收來自客戶端的控制命令，比如實(shí)現(xiàn)視頻文件的下載，以及關(guān)閉和開啟實(shí)時視頻監(jiān)控等功能。

2.3.1 NAL單元的提取與RTP數(shù)據(jù)包的傳輸

由于在達(dá)芬奇DM365開發(fā)平臺上的H.264編碼器的輸出碼流中，每個NAL單元前面有4個字節(jié)的前綴來標(biāo)識NAL單元邊，即起始碼前綴（0x00000001）。因此，Trans線程可以根據(jù)起始碼從已編碼緩沖區(qū)中提取出各個NAL單元以備發(fā)送，即從Video線程和Trans線程共享的緩沖區(qū)中獲得H.264編碼的圖像幀的數(shù)據(jù)，并在每幀的數(shù)據(jù)里搜尋出每個NAL單元。在默認(rèn)情況下，達(dá)芬奇DM365開發(fā)平臺采用的H.264編碼器每次提供一個完整的H.264視頻幀，除第一幀由三個NAL單元組成外，其他幀僅包含一個NAL單元。第一幀的三個NAL單元的類型分別為序列參數(shù)集（SPS）、圖像參數(shù)集（PPS）和IDR圖像片段。其他幀的NAL單元類型均為I圖像片段。

實(shí)時傳輸協(xié)議RTP負(fù)責(zé)提供實(shí)時數(shù)據(jù)（如交互式的音頻和視頻）的端到端傳輸服務(wù)，它可以建立在底層的面向連接或非面向連接的傳輸協(xié)議之上。通常情況下RTP數(shù)據(jù)包使用UDP來傳送，但它不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，而是依靠實(shí)時傳輸控制協(xié)議RTCP提供這些服務(wù)。本系統(tǒng)按RTP數(shù)據(jù)包格式將每一幀視頻打包后，使用UDP套接字將該數(shù)據(jù)包發(fā)送給客戶監(jiān)控端。

2.3.2 實(shí)時監(jiān)控的實(shí)現(xiàn)

4 結(jié)束語

本系統(tǒng)基于DM365嵌入式平臺，設(shè)計了嵌入式網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)。視頻服務(wù)器端主要實(shí)現(xiàn)視頻的采集、編碼與網(wǎng)絡(luò)傳輸，通過四個共享管道實(shí)現(xiàn)視頻數(shù)據(jù)流的共享，整個視頻服務(wù)器由五個線程相互配合完成?？蛻舯O(jiān)控端采用Davinci-VLC客戶端程序?qū)崿F(xiàn)視頻的監(jiān)控及視頻文件的備份。下一步的工作重點(diǎn)是研究基于WiFi+3G視頻監(jiān)控，以及保證視頻數(shù)據(jù)在網(wǎng)絡(luò)上的安全傳輸。

參考文獻(xiàn)：

[1] TI. DaVinci? Technology Overview.http：//focus.ti.com/lit/ml/sprb189b/sprb189b.pdf，2008.

[2] 韓慧英，潘婭.基于Davinci的嵌入式Web視頻監(jiān)控系統(tǒng)[J]. 兵工自動化，2010.29（4）：75-77

[3] 張多英，申晨，劉偉平，黃紅斌.嵌入式視頻監(jiān)控傳輸系統(tǒng)的設(shè)計與實(shí)現(xiàn)[J].計算機(jī)工程與設(shè)計，2010.31（4）：724-728

[4] 郭波，樊丁，彭凱.基于DaVinci技術(shù)的嵌入式視頻監(jiān)控系統(tǒng)設(shè)計[J].安防科技，2010.1：22-24，6

[5] Texas Instruments. Codec Engine Application Developers Guide[EB/OL].http：//processors.wiki.ti.com/index.php/Codec_Engine_Application_Developers_Guide，2010.