基于達芬奇技術的嵌入式網絡攝像機系統研究

肖 軍，徐熙平，李沛松（長春理工大學 光電工程學院，吉林 長春130022）

隨著多媒體技術和網絡技術的發展，網絡攝像機已經廣泛運用于網絡監控和視頻會議領域中。網絡攝像機的發展趨勢集視頻采集、視頻壓縮、視頻發送為一體，并且按照需求添加相應圖像識別、圖像疊加、運動偵測、云臺控制和報警等功能。因此要求處理芯片具有強大的控制能力和數據處理能力。TI公司推出了達芬奇技術，專門應用于多媒體系統，它把圖像處理的編碼算法封裝成標準API，應用程序調用這些API函數即可實現圖像的編碼處理。

TMS320DM368芯片是基于達芬奇技術的音視頻數字媒體片上系統(DMSoC)[1]，它以ARM926EJ-STM為內核，擁有兩個視頻圖像協處理器（HDVICP和MJCP），廣泛運用于中低端音視頻處理系統。本系統采用DM368來構建網絡攝像機視頻服務器，通過訪問服務器可實時查看監控視頻。

1 系統總體方案設計

TMS320DM368只有一個ARM內核，通過嵌入Linux系統來實現圖像的采集處理和網絡通信。系統總體框圖如圖1所示，CMOS圖像采集模塊把采集的數字圖像發送給TMS320DM368主芯片，然后調用算法API函數實現H.264編碼。UDP接收負責接收參數控制命令，經過命令解析把參數傳遞給對應模塊。RTSP負責等待客戶端訪問，然后創建用于RTP數據包發送的套接字。

為了實現系統功能，應用程序主要分為以下幾個線程：CMOS視頻采集線程、視頻編碼線程、RTSP任務調度線程、RTP視頻數據發送線程、UDP命令接收線程和命令解析線程。CMOS視頻采集線程負責按要求初始化CMOS芯片，采集視頻圖像；視頻編碼線程調用算法API接口，實現數據圖像的編碼壓縮；RTSP任務調度線程創建TCP套接字，等待客戶端的訪問連接，然后把所訪問客戶端的地址信息存放在調度任務中；RTP視頻數據發送線程把視頻數據通過RTP協議發送給指定客戶端；UDP命令接收線程負責接收客戶端發送的控制命令，然后發送給命令解析線程；命令解析線程把接收到的命令解析處理，把參數傳遞給對應模塊。

2 視頻采集和編碼

2.1 視頻采集模塊

視頻采集選用MT9P031型CMOS數字圖像傳感器芯片，感光面為1/2.5英寸，最大像素為 2592×1944。該芯片利用像素跳躍和像素混合技術，在不改變視場的情況下減少輸出圖像分辨率。它還提供I2C接口，主控器可以通過I2C接口設置CMOS輸出圖像的屬性，并且還集成了ADC轉換器，直接輸出12 bit數字圖像數據，在時鐘和行場同步信號作用下輸出每一幀圖像，如圖2所示。每一個場同步信號FV有效（高）表示一幀圖像，每一個場同步信號LV有效（高）表示該幀的一行，在行場同步都有效時每一個像素時鐘脈沖的Dout輸出就是對應像素的RGB值。若輸出一幀720 p的圖像，像素大小為 1280×720，每一個FV高電平區間就有720個LV高電平，在每一個LV高電平區間又有1 280個PCLK時鐘脈沖。

圖2 MT9P031輸出像素時序圖

TMS320DM368有一個ISIF接口，專門用于接收數字的視頻數據，芯片內部集成了ISIF圖像接收模塊，每接收到一幀完整的數據，芯片就會產生一個ISIF_INT中斷信號，在中斷響應程序里面可以把數據存放到指定地址。MT9P031和TMS320DM368的連接如圖3所示。MT9P031芯片的時鐘源由DM368GIO37引腳輸出提供，頻率為24 MHz，GIO91和GIO93引腳分別接復位和使能端。

圖3 MT9P031和TMS320DM368連接圖

2.2 H.264編碼模塊

對所采集的視頻數據進行編碼是通過調用Codec Engine算法包來實現的[2]。Codecs Engine是一組用來調用xDAIS算法的API，不管是在ARM端還是在DSP端，不管操作系統的差異，調用的API函數都是一致的。用戶只需要配置相應的*.cfg文件即可指定需要調用的算法，然后在應用程序中即可調用API函數進行算法編解碼。

H.264是一種高性能的視頻編解碼標準，繼承了H.263和MPEG1/2/4視頻編碼器的優點。H.264標準中定義了兩個層次：視頻編碼層（VCL）和網絡抽象層（NAL），VCL負責高效的數字視頻數據壓縮，NAL提供適當的接口對數據進行打包和傳送。

為了得到H.264格式的視頻流，本系統采用的H.264算法為TI發布的Codec Engine，配置 alg_server.cfg文件來實現對已經編譯算法的接口聲明，文件配置如下：

其中，name為調用算法的名字；mod用來標識實際的算法實現模塊；loacl指定算法運行在ARM端 (true)或者 DSP端(false)。

在應用程序中調用的接口函數有：VIDENC1_create、VIDENC1_control、VIDENC1_process 和 VIDENC1_delete。

3 視頻服務器的建立

3.1 搭建RTSP服務器

RTSP(Real Time Streaming Protocol)實時流協議是為了建立并控制一個或幾個時間同步的連續流媒體[3]，它本身不發送連續媒體流，只充當多媒體服務器的網絡遠程控制。

RTSP服務器需要預定義的方法有OPTION、DESCRIBE、SETUP、PLAY 和 TEARDOWN， 在 OPTION 響 應中需要實現服務器基本信息描述，DESCRIBE響應中需要向客戶端發送視頻的SDP信息，SETUP響應需要根據客戶端端口信息建立RTP（實時傳輸協議）視頻發送套接字，PLAY響應實現由RTP向客戶端發送視頻數據，TEAREOWN響應關閉對應RTP套接字，并且釋放對應的系統資源，流程如圖4所示。

3.2 RTP發送H.264視頻流

RTP(Real-Time Transport Protocol)實時傳輸協議是在多點傳送或單點傳送的網絡服務上提供端對端的網絡傳輸功能，適用于實時數據傳輸的場合[4]。RTP固定報頭格式如圖5所示。

定義報頭的數據格式如下：

圖4 RTSP服務器流程圖

圖5 RTP固定報頭格式

經編碼模塊輸出的H.264視頻流由一系列NAL單元（NALU）構成，每個 NALU由起始碼前綴(0x00000001)分隔開來[5]，所以RTP發送線程可以在輸出編碼流中提取出每個NALU，經過RTP協議轉換發送給客戶端。從編碼流中提取NALU單元流程如圖6所示。

經過驗證，對于720 p的H.264編碼輸出NALU負載長度不一，最大達到幾十字節，從網絡性能方面考慮，不宜發送過大的RTP數據包，為此采用RFC3984標準的FU-A方法對NALU進行分割，設置每個RTP包最大長度為1 400 B。于是對于不同負載長度的 NALU，RTP發送的數據包格式如表1所示。

定義結構體：

圖6 NAL單元提取流程圖

表1 RTP數據發送格式

其中，參數NaluHdr和FuIndic由NALU第一個字節決定，參數FuHdr用于設置分片發送的起始和結束RTP包。

本文研究了基于達芬奇技術的網絡攝像機系統，著重介紹了視頻采集、H.264算法的調用、RTSP視頻服務器以及利用RTP數據報發送。系統的應用程序采用多線程技術，提高了資源利用率和綜合性能。搭建的服務器專門用于H.264格式的視頻流發送，執行效率高，便于維護，對類似系統有很大的參考價值。基于TMS320DM368的網絡攝像機投入成本低，開發周期短，可以廣泛運用于各種監控系統。

[1]Texas Instruments Incorporated.TMS320DM368 Digital Media System-on-Chip(DMSoC)[EB/OL].[2011-06-30].http：//www.ti.com/lit/gpn/tms320dm368.

[2]Texas Instruments Incorporated.Codec Engine Application Developer User s Guide[A].http：//www.ti.com/lit/ug/sprue67d/sprue67d.pdf.

[3]SCHULZRINNE H，RAO A，LANPHIER R.Real time streaming protocol(RTSP)[S].RFC 2326，1998.

[4]SCHULZRINNE H，CASNER S，FREDERICK R.RTP：A transport protocolfor real-time applications[S].RFC 3550，2003.

[5]張多英.嵌入式視頻監控傳輸系統的設計與實現[J].計算機工程與設計，2010，31(4)：724-728.