江勇，杜程遠

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

?

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

江勇，杜程遠

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

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

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

引　言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在軟件開發(fā)上，海思半導體提供了媒體處理軟件平臺(Media Process Platform,MPP)，可支持應用軟件快速開發(fā)，MPP對應用軟件屏蔽了芯片相關的復雜的底層處理，并對應用軟件直接提供MPI(MPP Program Interface)接口完成相應的功能。MPP支持應用軟件快速開發(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內部處理流程圖

在我們的應用當中，海思媒體處理平臺的主要內部處理流程如圖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)絡攝像機中獲取視頻數(shù)據(jù)，所以網(wǎng)絡攝像機為視頻服務器，而Hi3531為獲取視頻數(shù)據(jù)的客戶端設備，對于網(wǎng)絡視頻服務器端和客戶端的交互，ONVIF規(guī)范中有許多的交互指令，在實際的開發(fā)中只用到了5條：設備發(fā)現(xiàn)指令、服務器能力查詢指令、服務器摘要認證指令、服務器視頻構架查詢指令和視頻流地址查詢指令。

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

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

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

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

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

3.3服務器媒體結構信息(Profile)查詢

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

3.4視頻流地址(Url)查詢

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

3.5服務器摘要認證

大部分的網(wǎng)絡攝像機在訪問的時候需要用戶名和密碼進行認證，客戶端和服務器端的用戶名和密碼的交互需要通過加密來進行，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結構體中將會加入wsse__Security數(shù)據(jù)段，在這個數(shù)據(jù)段中將放入鑒權的信息。在調用Capabilities/Profile/Url之前，都需要調用soap_wsse_add_UsernameTokenDigest()函數(shù)來進行鑒權，然后通過鑒權的結果來決定是否進行之后的操作。

4　RTSP握手流程

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

(1) OPTION操作

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

(2) DESCRIBE操作

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

(3) SETUP操作

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

(4) PLAY操作

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

(5) TEARDOWN操作

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

(6) 心跳操作

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

5　H.264壓縮視頻RTP打包結構和解包過程

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

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

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

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

③ 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是一幀的開始還是一幀的結束。

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

#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是一幀開始還是結束

*((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)軟件流程

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

structNETDEV_SERVER{

struct ONVIF_CONFIGOnvif_Info;//ONVIF交互信息

struct RTSP_CONFIGRtsp_Info;//RTSP交互信息

enum NETDEV_STATUSStatus_Info;

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

enum ERROR_CODEError_Info;//設備錯誤代碼

unsigned char ucUserName[16];//訪問設備用戶名

unsigned char ucPassWord[16];//訪問設備密碼

VDEC_CHN vdChn[16];//當前設備解碼通道

};

struct NETDEV_SERVER netVdoServer[128];

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

圖5　軟件主程序流程圖

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

結　語

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

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

[2] 海思半導體.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版.北京：清華大學出版社, 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

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