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

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

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

0 引言

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

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

DM365處理器集成了一個(gè)ARM926EJ-S內(nèi)核，一個(gè)H.264高清編解碼協(xié)處理器HDVICP和一個(gè)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算法來(lái)實(shí)現(xiàn)視頻編碼。

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

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

視頻監(jiān)控服務(wù)器的主要任務(wù)是監(jiān)聽(tīng)網(wǎng)絡(luò)連接，采集視頻數(shù)據(jù)，視頻數(shù)據(jù)壓縮編碼，存儲(chǔ)視頻數(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ù)器包括三個(gè)子模塊，一是視頻數(shù)據(jù)處理子模塊，負(fù)責(zé)視頻數(shù)據(jù)采集與編碼；二是視頻監(jiān)控控制子模塊，負(fù)責(zé)開(kāi)啟、關(guān)閉視頻監(jiān)控等控制操作；三是數(shù)據(jù)傳輸子模塊，負(fù)責(zé)視頻數(shù)據(jù)的實(shí)時(shí)傳輸以及備份視頻數(shù)據(jù)等工作。視頻監(jiān)控服務(wù)器模塊的工作流程如下。

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

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

③ Capture線程負(fù)責(zé)采集視頻信號(hào)；Video線程負(fù)責(zé)將視頻采集線程采集到的視頻信號(hào)用H.264編碼器壓縮編碼；Trans線程負(fù)責(zé)將壓縮后的視頻數(shù)據(jù)存儲(chǔ)在視頻服務(wù)器端的硬盤上，并實(shí)時(shí)地將視頻流傳輸給視頻監(jiān)控端；Listen線程主要負(fù)責(zé)監(jiān)聽(tīng)客戶監(jiān)控端的控制命令，并對(duì)命令進(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ū)被多個(gè)線程共享。共享的方法是采用管道通信，一方將緩沖區(qū)的地址送入管道，另一方從管道讀取緩沖區(qū)地址對(duì)該緩沖區(qū)共享。

2.2.1 緩沖區(qū)共享

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

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

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

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

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

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

④ Video線程從VTOutFifo管道中獲取一個(gè)空緩沖區(qū)hDstBuf，并對(duì)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線程從管道獲取一個(gè)已編碼的緩沖區(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)動(dòng)補(bǔ)償?shù)幕A(chǔ)上，采用全新的幀內(nèi)預(yù)測(cè)、多幀參考預(yù)測(cè)、高精度運(yùn)動(dòng)估計(jì)、類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)中定義了兩個(gè)層次：視頻編碼層（VCL）和網(wǎng)絡(luò)抽象層（NAL）。VCL主要負(fù)責(zé)高效的數(shù)字視頻數(shù)據(jù)壓縮。VCL處理的是塊、宏塊和片的數(shù)據(jù)，并盡可能地設(shè)計(jì)成不依賴于任何網(wǎng)絡(luò)的特性。NAL處理的主要是片以上的數(shù)據(jù)，提供適當(dāng)?shù)慕涌趯?duì)數(shù)據(jù)進(jìn)行打包和傳送。在VCL和NAL之間定義了一個(gè)基于分組方式的接口。這樣，高編碼效率和網(wǎng)絡(luò)友好性的任務(wù)分別由VCL和NAL來(lái)完成。H.264的這種雙結(jié)構(gòu)擴(kuò)大了應(yīng)用范圍，幾乎涵蓋了視頻監(jiān)控、視頻點(diǎn)播、流媒體業(yè)務(wù)等大部分的視頻業(yè)務(wù)。

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

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

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

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

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

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

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

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

4 結(jié)束語(yǔ)

本系統(tǒng)基于DM365嵌入式平臺(tái)，設(shè)計(jì)了嵌入式網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)。視頻服務(wù)器端主要實(shí)現(xiàn)視頻的采集、編碼與網(wǎng)絡(luò)傳輸，通過(guò)四個(gè)共享管道實(shí)現(xiàn)視頻數(shù)據(jù)流的共享，整個(gè)視頻服務(wù)器由五個(gè)線程相互配合完成。客戶監(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]. 兵工自動(dòng)化，2010.29（4）：75-77

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

[4] 郭波，樊丁，彭凱.基于DaVinci技術(shù)的嵌入式視頻監(jiān)控系統(tǒng)設(shè)計(jì)[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.