基于Hi3531的ONVIF高清網絡攝像機視頻數據接入設計

江勇，杜程遠

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

?

基于Hi3531的ONVIF高清網絡攝像機視頻數據接入設計

江勇，杜程遠

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

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

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

引　言

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

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

1　網絡攝像機設備中的ONVIF規范簡介

為了讓不同廠家的網絡視頻設備完全互聯互通，ONVIF規范描述了網絡視頻的接口、數據類型和數據交互的方式，它的目標是制定一套相對完整的網絡視頻交互的框架協議。

針對網絡攝像機設備，使用到的ONVIF協議規范，主要有以下兩部分:

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

② ONVIF協議中的視頻數據流則通過RTP/RTSP[4]協議來進行傳輸。

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

圖1　網絡攝像機設備中使用的ONVIF規范的框架

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

另外，在ONVIF規范中，H.264壓縮視頻數據是在RTSP協議的控制下進行傳輸的，RTSP協議是一種多媒體播放控制協議，在控制信息中帶有與音視頻相關的時間信息，所以它可以實現音視頻的同步、暫停、繼續、后退、前進等動作，可實現網絡視頻的播放控制。

2　Hi3531特性和H.264視頻數據解壓流程

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

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

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

圖2　網絡攝像機數據流在各個硬件模塊間的傳遞示意圖

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

圖3　Hi3531典型的系統層次圖

圖4　H.264壓縮視頻在Hi3531內部處理流程圖

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

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

3　基于Hi3531的ONVIF規范的實現

Hi3531從網絡攝像機中獲取視頻數據，所以網絡攝像機為視頻服務器，而Hi3531為獲取視頻數據的客戶端設備，對于網絡視頻服務器端和客戶端的交互，ONVIF規范中有許多的交互指令，在實際的開發中只用到了5條：設備發現指令、服務器能力查詢指令、服務器摘要認證指令、服務器視頻構架查詢指令和視頻流地址查詢指令。

通過移植gSOAP工具，并調用工具中已經封裝好的函數接口來實現以上的交互過程，并實現鑒權認證的功能。

3.1設備發現

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

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

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

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

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

3.4視頻流地址(Url)查詢

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

3.5服務器摘要認證

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

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

4　RTSP握手流程

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

(1) OPTION操作

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

(2) DESCRIBE操作

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

(3) SETUP操作

之后，客戶端發起SETUP連接請求，指定用于流媒體的傳輸機制的建立，在請求操作中，客戶端將告訴服務器端視頻數據所需要傳送的使用TCP方式還是UDP方式，并告訴服務器端傳輸數據時使用的端口號，在收到服務器端的OK指令后，建立數據傳輸和指令傳輸的套接字。注意，如果使用UDP協議傳輸，則數據傳輸的端口號必須是偶數，指令傳輸的端口號必須是奇數。

(4) PLAY操作

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

(5) TEARDOWN操作

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

(6) 心跳操作

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

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

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

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

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

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

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

如果一幀數據被分為多個RTP包，則接下來的一個字節的前兩比特將指示這個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　系統軟件流程

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

structNETDEV_SERVER{

struct ONVIF_CONFIGOnvif_Info;//ONVIF交互信息

struct RTSP_CONFIGRtsp_Info;//RTSP交互信息

enum NETDEV_STATUSStatus_Info;

//設備狀態：離線，在線，顯示

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解碼網絡攝像頭視頻數據圖像。

圖5　軟件主程序流程圖

圖6　Hi3531解碼網絡視頻攝像機視頻數據4宮格圖像

結　語

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

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

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

[3] 顧寧,劉家茂,柴曉路,等.Web Services原理與研發實踐[M].北京：機械工業出版社，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)