基于Hi3531的ONVIF高清網(wǎng)絡(luò)攝像機視頻數(shù)據(jù)接入設(shè)計

江勇，杜程遠

(深圳市屏源科技有限公司 研發(fā)中心，深圳518055)

?

基于Hi3531的ONVIF高清網(wǎng)絡(luò)攝像機視頻數(shù)據(jù)接入設(shè)計

江勇，杜程遠

(深圳市屏源科技有限公司 研發(fā)中心，深圳518055)

基于海思半導(dǎo)體的嵌入式32位視頻處理器Hi3531，提出了接入兼容ONVIF規(guī)范的高清網(wǎng)絡(luò)攝像機視頻數(shù)據(jù)的方法，描述了兼容ONVIF規(guī)范的客戶端和服務(wù)器端的握手過程，介紹了H.264視頻流的RTSP數(shù)據(jù)包的結(jié)構(gòu)和解RTSP數(shù)據(jù)包的流程和實例。該設(shè)計被用于LED/LCD多屏拼接設(shè)備的基于IP的視頻數(shù)據(jù)的接入，取得了很好的效果。

視頻處理器；Hi3531; ONVIF；RTSP；H.264

引　言

網(wǎng)絡(luò)攝像機等網(wǎng)絡(luò)視頻設(shè)備越來越多地使用在安防、安監(jiān)等領(lǐng)域并得到廣泛應(yīng)用，這些網(wǎng)絡(luò)視頻設(shè)備的生產(chǎn)商有幾百家，為了解決不同廠家的網(wǎng)絡(luò)視頻設(shè)備兼容性問題，2008年5月，安迅士聯(lián)合博世以及索尼公司，共同成立一個國際開放型網(wǎng)絡(luò)視頻產(chǎn)品標(biāo)準網(wǎng)絡(luò)接口開發(fā)論壇，取名為ONVIF[1](Open Network Video Interface Forum，開放型網(wǎng)絡(luò)視頻接口論壇)，并以公開、開放的原則共同制定開放性行業(yè)標(biāo)準。

基于海思半導(dǎo)體推出的Hi3531[2]高性能視頻處理器設(shè)計的網(wǎng)絡(luò)視頻接入系統(tǒng)，完全可以將符合ONVIF規(guī)范的網(wǎng)絡(luò)設(shè)備的視頻數(shù)據(jù)接入到嵌入式系統(tǒng)當(dāng)中，本文以高清網(wǎng)絡(luò)攝像機視頻數(shù)據(jù)的接入為例，闡述了對接的整個過程。

1　網(wǎng)絡(luò)攝像機設(shè)備中的ONVIF規(guī)范簡介

為了讓不同廠家的網(wǎng)絡(luò)視頻設(shè)備完全互聯(lián)互通，ONVIF規(guī)范描述了網(wǎng)絡(luò)視頻的接口、數(shù)據(jù)類型和數(shù)據(jù)交互的方式，它的目標(biāo)是制定一套相對完整的網(wǎng)絡(luò)視頻交互的框架協(xié)議。

針對網(wǎng)絡(luò)攝像機設(shè)備，使用到的ONVIF協(xié)議規(guī)范，主要有以下兩部分:

① 設(shè)備管理和控制部分的接口規(guī)范，這部分管理和接口規(guī)范均以Web Services形式提供，每個支持ONVIF規(guī)范的網(wǎng)絡(luò)視頻設(shè)備都必須提供相應(yīng)的Web service, 網(wǎng)絡(luò)視頻的服務(wù)器端和客戶端的Web Service[3]采用SOAP協(xié)議來進行交互；

② ONVIF協(xié)議中的視頻數(shù)據(jù)流則通過RTP/RTSP[4]協(xié)議來進行傳輸。

圖1簡單地描述了在網(wǎng)絡(luò)攝像機設(shè)備中使用到的ONVIF規(guī)范的大致框架。

圖1　網(wǎng)絡(luò)攝像機設(shè)備中使用的ONVIF規(guī)范的框架

從圖1中可以看到，SOAP協(xié)議封裝了用XML語言描述的服務(wù)器端和客戶端的交互數(shù)據(jù)，SOAP(Simple Object Access Protocol，簡單對象訪問協(xié)議)是一種基于XML的，被設(shè)計在Web上交換結(jié)構(gòu)化和固化的信息。在實際的開發(fā)當(dāng)中，使用gSOAP工具提供一組透明化的SOAP API,將與開發(fā)無關(guān)的SOAP實現(xiàn)細節(jié)內(nèi)容對用戶隱藏起來，通過將XML文件解析序列化為C/C++語言，實現(xiàn)開發(fā)與具體SOAP協(xié)議的無關(guān)性。

另外，在ONVIF規(guī)范中，H.264壓縮視頻數(shù)據(jù)是在RTSP協(xié)議的控制下進行傳輸?shù)模琑TSP協(xié)議是一種多媒體播放控制協(xié)議，在控制信息中帶有與音視頻相關(guān)的時間信息，所以它可以實現(xiàn)音視頻的同步、暫停、繼續(xù)、后退、前進等動作，可實現(xiàn)網(wǎng)絡(luò)視頻的播放控制。

2　Hi3531特性和H.264視頻數(shù)據(jù)解壓流程

海思半導(dǎo)體推出的H.264編解碼處理器Hi3531，是針對嵌入式網(wǎng)絡(luò)視頻產(chǎn)品應(yīng)用設(shè)計的高端SoC，它內(nèi)置高性能主頻1 GHz的Cortex-A9處理器、一個H.264/MPEG4視頻編碼器硬核、一個H.264/MPEG4視頻解碼器硬核，能夠?qū)崿F(xiàn)5路1080P視頻數(shù)據(jù)實時多協(xié)議編解碼。

在視頻接口上，Hi3531集成一路HDMI高清輸出、一路VGA高清輸出、一路BT1120高清輸出和4路BT1120高清視頻信號輸入接口；另外還集成兩路千兆以太網(wǎng)接口，內(nèi)置專用的TOE網(wǎng)絡(luò)加速模塊。

在設(shè)計中，視頻信號輸入板式需要將網(wǎng)絡(luò)攝像機的視頻接入拼接處理器設(shè)備，所以需要最多能夠接入128路網(wǎng)絡(luò)攝像機設(shè)備，每個Hi3531單元能顯示16路CIF分辨率的視頻數(shù)據(jù)或4路1080P分辨率的視頻數(shù)據(jù)。于是，網(wǎng)絡(luò)數(shù)據(jù)流在各個硬件模塊間的流動如圖2所示。

圖2　網(wǎng)絡(luò)攝像機數(shù)據(jù)流在各個硬件模塊間的傳遞示意圖

在軟件開發(fā)上，海思半導(dǎo)體提供了媒體處理軟件平臺(Media Process Platform,MPP)，可支持應(yīng)用軟件快速開發(fā)，MPP對應(yīng)用軟件屏蔽了芯片相關(guān)的復(fù)雜的底層處理，并對應(yīng)用軟件直接提供MPI(MPP Program Interface)接口完成相應(yīng)的功能。MPP支持應(yīng)用軟件快速開發(fā)以下功能：輸入視頻捕獲、H.264/MJPEG/JPEG/MPEG4編碼、H.264/VC1/MPEG4/MPEG2/AVS解碼、視頻輸出顯示、視頻圖像處理、編碼流疊加OSD等。MPP平臺支持的典型的系統(tǒng)層次如圖3所示。

圖3　Hi3531典型的系統(tǒng)層次圖

圖4　H.264壓縮視頻在Hi3531內(nèi)部處理流程圖

在我們的應(yīng)用當(dāng)中，海思媒體處理平臺的主要內(nèi)部處理流程如圖4所示，主要分為H.264壓縮視頻輸入(CVI)、視頻解碼(VDEC)、視頻處理(VPSS)、視頻輸出(VO)等模塊。

在使用MPP時，需要獲取某一路H.264壓縮視頻數(shù)據(jù)并綁定到一路視頻解碼通道，再將這一路解碼通道綁定到一路視頻處理通道上，最后將這一路視頻處理通道綁定到一路視頻輸出通道上，這樣就建立了一條完整的壓縮視頻數(shù)據(jù)處理的鏈路。這一路的H.264壓縮視頻數(shù)據(jù)流將會沿著建立完成的數(shù)據(jù)流通道完成整個數(shù)據(jù)處理流程，而CPU的工作只需在初始化MPP時為每一路H.264的壓縮視頻建立一條通道。

3　基于Hi3531的ONVIF規(guī)范的實現(xiàn)

Hi3531從網(wǎng)絡(luò)攝像機中獲取視頻數(shù)據(jù)，所以網(wǎng)絡(luò)攝像機為視頻服務(wù)器，而Hi3531為獲取視頻數(shù)據(jù)的客戶端設(shè)備，對于網(wǎng)絡(luò)視頻服務(wù)器端和客戶端的交互，ONVIF規(guī)范中有許多的交互指令，在實際的開發(fā)中只用到了5條：設(shè)備發(fā)現(xiàn)指令、服務(wù)器能力查詢指令、服務(wù)器摘要認證指令、服務(wù)器視頻構(gòu)架查詢指令和視頻流地址查詢指令。

通過移植gSOAP工具，并調(diào)用工具中已經(jīng)封裝好的函數(shù)接口來實現(xiàn)以上的交互過程，并實現(xiàn)鑒權(quán)認證的功能。

3.1設(shè)備發(fā)現(xiàn)

客戶端設(shè)備首先要搜索網(wǎng)絡(luò)中所有符合ONVIF協(xié)議規(guī)范的網(wǎng)絡(luò)攝像機，搜索的原理是向網(wǎng)絡(luò)中廣播地址的3702端口通過UDP協(xié)議發(fā)送搜索用廣播包，每一個在網(wǎng)絡(luò)上的ONVIF服務(wù)器設(shè)備在收到廣播包后，將會向客戶端設(shè)備回復(fù)一個hello信息，hello信息中包含服務(wù)器的IP地址、端口號、生產(chǎn)廠家、設(shè)備類型等信息，客戶端設(shè)備收到信息后就可以根據(jù)hello信息中包含的服務(wù)器信息和服務(wù)器進行單獨的交互。

3.2服務(wù)器能力信息(Capabilities)查詢

在通過設(shè)備發(fā)現(xiàn)獲取到視頻服務(wù)器的IP地址、端口號等信息后，就可以通過這些信息來獲取視頻服務(wù)器的能力信息，能力信息包括服務(wù)器的網(wǎng)絡(luò)信息、設(shè)備相關(guān)信息和媒體信息等。在網(wǎng)絡(luò)攝像機設(shè)備中，只需要提取到媒體信息，在gSoap工具函數(shù)中只需調(diào)用Soap_call___tds__GetCapabilities()函數(shù)，就可以實現(xiàn)服務(wù)器端能力信息的獲取。

3.3服務(wù)器媒體結(jié)構(gòu)信息(Profile)查詢

在獲取到服務(wù)器設(shè)備的能力信息后，需要通過設(shè)備的能力信息去獲取服務(wù)器設(shè)備的媒體構(gòu)架信息，在應(yīng)用中就是要知道服務(wù)器端可以提供多少路媒體數(shù)據(jù)(包括音頻和視頻數(shù)據(jù))，獲取每一路媒體數(shù)據(jù)的標(biāo)識符。在gSoap工具中，通過調(diào)用soap_call___trt__GetProfiles()函數(shù)獲取媒體結(jié)構(gòu)信息。大部分的網(wǎng)絡(luò)攝像機都能提供兩路視頻數(shù)據(jù)：一路高分辨率視頻圖像，即主碼流；一路低分辨率視頻圖像，即輔碼流，還有一部分可以提供3路甚至更多路的視頻數(shù)據(jù)流。

3.4視頻流地址(Url)查詢

以上所有的工作是為了獲取服務(wù)器設(shè)備上所需的視頻數(shù)據(jù)流的地址信息，即服務(wù)器中相應(yīng)的每一種視頻數(shù)據(jù)碼流的獲取地址，以便讓RTSP協(xié)議通過視頻流地址去獲取所需要的視頻數(shù)據(jù)。我們通過調(diào)用gSoap工具中的Soap_call___trt__GetStreamUri()函數(shù)來獲取相應(yīng)的視頻數(shù)據(jù)流的地址信息，在RTSP協(xié)議中這些信息將被使用到。

3.5服務(wù)器摘要認證

大部分的網(wǎng)絡(luò)攝像機在訪問的時候需要用戶名和密碼進行認證，客戶端和服務(wù)器端的用戶名和密碼的交互需要通過加密來進行，ONVIF規(guī)范中定義使用摘要加密的方式來完成。Soap通信的驗證機制是WS_UsernameToken，流加密的方式是HTTP。所謂的WS_UsernameToken加密，就是將用戶名、密碼、摘要驗證的隨機數(shù)、時間信息都包含在數(shù)據(jù)頭中進行加密。

在具體的實現(xiàn)中，先移植了openssl[5]，因為在gSOAP工具提供的函數(shù)中將用到里面的庫文件，然后在onvif.h文件中加入import “wsse.h”，這樣在最后生成代碼的SOAP_ENV__Header結(jié)構(gòu)體中將會加入wsse__Security數(shù)據(jù)段，在這個數(shù)據(jù)段中將放入鑒權(quán)的信息。在調(diào)用Capabilities/Profile/Url之前，都需要調(diào)用soap_wsse_add_UsernameTokenDigest()函數(shù)來進行鑒權(quán)，然后通過鑒權(quán)的結(jié)果來決定是否進行之后的操作。

4　RTSP握手流程

ONVIF規(guī)范定義的是獲取媒體流信息的過程，而RTSP握手協(xié)議定義的是實際操作的流程，在實際開發(fā)中使用到了其中的幾個操作。

(1) OPTION操作

客戶端向獲得的流媒體地址發(fā)起OPTION操作請求，服務(wù)器端返回服務(wù)端信息及其支持的操作方法，其中包括OPTION、DESCRIBE、SETUP、PLAY和TEARDOWN等。

(2) DESCRIBE操作

客戶端再次向流媒體地址發(fā)起DESCRIBE連接請求，檢查媒體對象的描述，服務(wù)器端返回媒體對象的描述信息。

(3) SETUP操作

之后，客戶端發(fā)起SETUP連接請求，指定用于流媒體的傳輸機制的建立，在請求操作中，客戶端將告訴服務(wù)器端視頻數(shù)據(jù)所需要傳送的使用TCP方式還是UDP方式，并告訴服務(wù)器端傳輸數(shù)據(jù)時使用的端口號，在收到服務(wù)器端的OK指令后，建立數(shù)據(jù)傳輸和指令傳輸?shù)奶捉幼帧Ｗ⒁?，如果使用UDP協(xié)議傳輸，則數(shù)據(jù)傳輸?shù)亩丝谔柋仨毷桥紨?shù)，指令傳輸?shù)亩丝谔柋仨毷瞧鏀?shù)。

(4) PLAY操作

最后，客戶端向流媒體地址發(fā)起PLAY請求，以SETUP指定的機制開始發(fā)送數(shù)據(jù)，服務(wù)器端將開始向客戶端發(fā)送指定的多媒體數(shù)據(jù)。

(5) TEARDOWN操作

在用戶端需要斷開數(shù)據(jù)流的傳輸時，客戶端需要向服務(wù)器端發(fā)送TEARDOWN指令，服務(wù)器端在收到TEARDOWN操作指令后將拆除兩者之間建立的數(shù)據(jù)連接，關(guān)閉RTSP的連接通道，數(shù)據(jù)發(fā)送過程終止。

(6) 心跳操作

對大部分的網(wǎng)絡(luò)攝像機設(shè)備，客戶端在連接后都需要定時向它們發(fā)送一條指令數(shù)據(jù)以維持當(dāng)前的數(shù)據(jù)連接，這條維持連接的操作就是心跳操作。網(wǎng)絡(luò)攝像機設(shè)備如果在一定的時間內(nèi)沒有收到心跳數(shù)據(jù)包，將會自動終止數(shù)據(jù)的傳輸，拆除之前搭建的通道。這個心跳間隔每個廠家生產(chǎn)的設(shè)備都不是一樣的，在實際開發(fā)中，每3 s將向所有的網(wǎng)絡(luò)攝像機設(shè)備發(fā)送一條OPTION的操作指令來完成維持心跳的操作。

5　H.264壓縮視頻RTP打包結(jié)構(gòu)和解包過程

在RFC3550規(guī)范中定義了RTP報文頭格式，一共12個字節(jié)，包含了版本號、負載類型、序列號和時間戳等信息，本設(shè)計中這12個字節(jié)的頭信息是可以完全丟棄的。

接下來是網(wǎng)絡(luò)抽象層單元(NALU)，NALU頭由一個字節(jié)組成，它的語法如下。

① Forbidden_zero_bit(F): 1比特，在H.264規(guī)范中定義必須為0。

② Nal_ref_idc(NRI): 2比特，取00 ～ 11，定義了此NALU的重要度。如果是00，解碼器可以丟棄它而不影響圖像的回放，一般不太需要關(guān)注這個屬性。

③ Type: 5比特，它定義了這個NALU單元的類型。使用RTP協(xié)議傳輸?shù)腍.264數(shù)據(jù)一般分為三種類型：一個包一個H.264數(shù)據(jù)幀(類型編號為23),一個包多個H.264數(shù)據(jù)幀(類型編號為24～27),一幀數(shù)據(jù)被分為多個RTP包(類型編號為28)。

如果一幀數(shù)據(jù)被分為多個RTP包，則接下來的一個字節(jié)的前兩比特將指示這個NALU是一幀的開始還是一幀的結(jié)束。

在實際的設(shè)計當(dāng)中，需要把NALU頭解析出來，加上H.264的頭{0x00,0x00,0x00,0x01},然后送到解碼器解碼就可以了。設(shè)計的解包程序如下：

#define RTP_HEADLEN 12

int unpackRTPH264(char *inbuf, intrlen,char *outbuf){

unsignedchar *src = (unsigned char *)inbuf + RTP_HEADLEN;

unsigned char head1 = *src;

unsigned char head2 = *(src + 1);

unsigned char nal = head1 & 0x1f;

unsigned char flag = head2 & 0xe0;

unsigned char nal_fu = (head1 & 0xe0) | (head2 & 0x1f);

if(nal == 0x1c){//判斷RTP包類型

if(flag == 0x80){//判斷NALU是一幀開始還是結(jié)束

*((int *)outbuf) = 0x01000000;

*((char *)outbuf + 4) = nal_fu;

memcpy(outbuf + 5,inbuf + RTP_HEADLEN + 2,rlen - RTP_HEADLEN - 2);

return(rlen - RTP_HEADLEN + 3);

}

else{

memcpy(outbuf,inbuf + RTP_HEADLEN + 2,rlen - RTP_HEADLEN - 2);

return(rlen - RTP_HEADLEN - 2);

}

}

else{

*((int *)outbuf) = 0x01000000;

memcpy(outbuf + 4,inbuf + RTP_HEADLEN,rlen - RTP_HEADLEN);

return(rlen - RTP_HEADLEN + 4);

}

}

6　系統(tǒng)軟件流程

軟件設(shè)計中，針對每一個網(wǎng)絡(luò)攝像機設(shè)備需要構(gòu)造一個數(shù)據(jù)結(jié)構(gòu)模型來描述與之相關(guān)的所有的信息，建立一個順序表netServer[n]來存放每一個網(wǎng)絡(luò)攝像機的ONVIF交互信息、RTSP的交互信息、設(shè)備錯誤信息、設(shè)備狀態(tài)等所有數(shù)據(jù)。這個順序表的大小n，決定了系統(tǒng)能接入多少個網(wǎng)絡(luò)視頻設(shè)備，而軟件中所有的操作都圍繞著這組數(shù)據(jù)結(jié)構(gòu)模型來進行。此數(shù)據(jù)結(jié)構(gòu)的定義如下：

structNETDEV_SERVER{

struct ONVIF_CONFIGOnvif_Info;//ONVIF交互信息

struct RTSP_CONFIGRtsp_Info;//RTSP交互信息

enum NETDEV_STATUSStatus_Info;

//設(shè)備狀態(tài)：離線，在線，顯示

enum ERROR_CODEError_Info;//設(shè)備錯誤代碼

unsigned char ucUserName[16];//訪問設(shè)備用戶名

unsigned char ucPassWord[16];//訪問設(shè)備密碼

VDEC_CHN vdChn[16];//當(dāng)前設(shè)備解碼通道

};

struct NETDEV_SERVER netVdoServer[128];

軟件的主程序流程如圖5所示。圖6是4宮格Hi3531解碼網(wǎng)絡(luò)攝像頭視頻數(shù)據(jù)圖像。

圖5　軟件主程序流程圖

圖6　Hi3531解碼網(wǎng)絡(luò)視頻攝像機視頻數(shù)據(jù)4宮格圖像

結(jié)　語

在Hi3531平臺上實現(xiàn)ONVIF規(guī)范的網(wǎng)絡(luò)攝像機視頻數(shù)據(jù)的接入是一個很復(fù)雜的工程，涉及到ONVIF協(xié)議規(guī)范實現(xiàn)、RTSP數(shù)據(jù)解包、Hi3531平臺的H.264解碼和嵌入式Linux多任務(wù)編程[6]等多種軟件技術(shù)。在產(chǎn)品化過程中，還碰到許多細節(jié)的技術(shù)問題(如顯示模式切換、錯誤處理、心跳包處理、線程的切換管理等)，同樣需要耗費大量的時間去一一解決。以此開發(fā)的網(wǎng)絡(luò)視頻接入單元在LED/LCD多屏拼接器[7]設(shè)備中被大量使用，穩(wěn)定可靠，在用戶中贏得很好的口碑。

[1] ONVIF協(xié)議中文原版[EB/OL].[2016-03].http://wenku.baidu.com/link?url=2G2Dv6Lr8JHYz6QbJKy Y49F34Xpfu 636NN3bKRkZtzhQ6cFwJlC4EpOPyFkinmoAm4dQJvvWWIKY CWkwWMdROaO8E-lhZiIlUpYxvjMVmZu.

[2] 海思半導(dǎo)體.Hi3531 H.264編解碼處理器用戶指南, 2014.

[3] 顧寧,劉家茂,柴曉路,等.Web Services原理與研發(fā)實踐[M].北京：機械工業(yè)出版社，2006.

[4] RFC 2326-1998 Real time streaming protocol(RTSP)[S].

[5] Openssl org, openssl Cryptography and SSL/TLS Toolkit[EB/OL].[2016-03].http://www.openssl.org.

[6] Kurt Wall.GNU/Linux編程指南[M].2版.北京：清華大學(xué)出版社, 2002.

ONVIF High-resolution Network Camera Video Data Access Based on Hi3531

Jiang Yong,Du Chengyuan

(R&D Center,Shenzhen Tien Wall Hi-tech Co.,Ltd.,Shenzhen 518055,China)

Based on the hisilicon 32-bit embedded video processor Hi3531,the method of access compatible ONVIF specification network HD camera video data is proposed.The handshake process of client and server-side is described.The structure of RTSP data which includes H.264 video stream and the process of unpack the RTSP data are introduced.This design is used to access the LED/LCD multi-screen device based on the IP video data.

video processor;Hi3531;ONVIF specification;RTSP protocol;H.264

TN919

A

(責(zé)任編輯：楊迪娜2016-03-28)