基于ONVIF協(xié)議的媒體流實(shí)現(xiàn)方法

張茜

（武漢郵電科學(xué)研究院 湖北 武漢 430000）

現(xiàn)在隨著網(wǎng)絡(luò)技術(shù)和多媒體技術(shù)的不斷發(fā)展以及網(wǎng)絡(luò)技術(shù)和多媒體技術(shù)結(jié)合應(yīng)用的不斷深入，在互聯(lián)網(wǎng)上傳播圖形、圖像、音頻、視頻已經(jīng)越來越廣泛了。多媒體的應(yīng)用具有連續(xù)性、實(shí)時性等特點(diǎn)，普遍對端到端的延遲和延遲變化比較敏感，但容許一定程度數(shù)據(jù)丟失。流媒體技術(shù)就是為適應(yīng)這種多媒體在網(wǎng)絡(luò)中的應(yīng)用和發(fā)展而產(chǎn)生的，所謂流媒體就是在網(wǎng)絡(luò)上流式傳輸?shù)亩嗝襟w。

2008年安訊士、博世、索尼等三家公司共同推出了ONVIF協(xié)議。ONVIF網(wǎng)絡(luò)視頻協(xié)議的出現(xiàn)，解決了各類設(shè)備不能融合使用的難題，提供了統(tǒng)一的網(wǎng)絡(luò)視頻開發(fā)標(biāo)準(zhǔn)，即最終能夠通過ONVIF這個標(biāo)準(zhǔn)化的平臺實(shí)現(xiàn)不同產(chǎn)品之間的集成。本論文課題來源于實(shí)習(xí)過程中一個視頻監(jiān)控系統(tǒng)項(xiàng)目，目的是為了介紹ONVIF協(xié)議的是怎樣規(guī)定和實(shí)現(xiàn)網(wǎng)絡(luò)刻錄機(jī)（NVR）與網(wǎng)絡(luò)攝像頭（IPC）之間媒體流的傳輸。在NVR與IPC進(jìn)行媒體通信的過程主要存在的問題有：

1）NVR與IPC之間如何進(jìn)行通信；

2）NVR與IPC之間進(jìn)行媒體數(shù)據(jù)的傳輸需要進(jìn)行什么準(zhǔn)備；

3）媒體數(shù)據(jù)怎樣在RTP上面進(jìn)行傳輸；

4）RTP上面?zhèn)鬏數(shù)拿襟w數(shù)據(jù)與H264的媒體數(shù)據(jù)的格式有何區(qū)別以及如何進(jìn)行相互的轉(zhuǎn)換。

1 基本思想

1.1 運(yùn)用onvif的優(yōu)點(diǎn)

Onvif協(xié)議由于采用WSDL+XML模式，使的其后續(xù)擴(kuò)展不會遇到太多的麻煩。XML極強(qiáng)的擴(kuò)展性與SOAP協(xié)議開發(fā)的便捷性將吸引到更多的人來關(guān)注和使用ONVIF規(guī)范。NVR的兼容與開放就顯得非常迫切和必要了。通過ONVIF協(xié)議可以擴(kuò)張NVR的開放和兼容，因?yàn)镺NVIF的標(biāo)準(zhǔn)接口可以解決非標(biāo)準(zhǔn)化網(wǎng)絡(luò)攝像機(jī)通過RTSP流媒體協(xié)議解決接入問題；ONVIF協(xié)議規(guī)定的視頻編碼技術(shù)，進(jìn)一步促進(jìn)了NVR與前端之間自由無阻的通信。

與此同時，一些基于ONVIF的NVR產(chǎn)品的開放性還開始向深度化管理延伸，從而讓NVR與前端攝像機(jī)的互通不僅僅只停留在視頻接入和瀏覽這一簡單應(yīng)用上，比如，通過NVR實(shí)現(xiàn)對第三方品牌攝像機(jī)進(jìn)行告警、輔助開關(guān)、參數(shù)的系統(tǒng)設(shè)置以及系統(tǒng)升級、視頻參數(shù)調(diào)節(jié)、3D定焦等[2]。

1.2 技術(shù)路線

1）根據(jù)onvif協(xié)議確定中NVR與IPC對接的接口。通過接口的描述確定重要參數(shù)以及獲取的方式，如果在參數(shù)獲取失敗則使用Onvif測試工具對問題進(jìn)行定位。

2）理解RTSP的建立流程對對其進(jìn)行實(shí)現(xiàn)，從而獲取媒體流。

3）將媒體流進(jìn)行解碼，使得網(wǎng)絡(luò)攝像頭的圖像可以顯示在NVR的界面上。

以上的幾個部分的實(shí)現(xiàn)都在NETCLIENT協(xié)議模塊。NETCLIENT協(xié)議模塊中建立一個ipcamera的單件對象，該對象處理所有與NVR系統(tǒng)相關(guān)的核心事件，派生出使用各種協(xié)議IPC的子對象負(fù)責(zé)IPC各事件的具體實(shí)現(xiàn)。rtsp_live對象負(fù)責(zé)調(diào)用Live555接口完成傳輸IPC中接收到的媒體數(shù)據(jù)。登錄每個IPC都是一次完整的處理流程。

主要處理過程如圖1所示。

圖1 NVR與IPC通信主要流程Fig.1 NVR and IPC communication major processes

流程圖如圖2所示。

圖2 NVR與IPC通信過程Fig.2 NVR and IPC communication process

2 實(shí)驗(yàn)方案

文中采用gSOAP工具開發(fā)的0NVIF協(xié)議。接下來的工作是在描述基于gSOAP工具的0NVIF協(xié)議基礎(chǔ)上，詳細(xì)分析NVR和IPC之間預(yù)覽功能的實(shí)現(xiàn)。

2.1 實(shí)現(xiàn)對ipc的登陸

要實(shí)現(xiàn)對ipc的登陸，就需要正確獲得ipc的登陸所需要的各項(xiàng)配置例如權(quán)限的獲取，URL的獲取，ipc媒體流的獲取，還有ipc的媒體端口號，ip地址，以及時間。這其中較難獲取的是ipc的配置以及uri的獲取。當(dāng)我們獲取各項(xiàng)之后如果還不能登陸后者是有其他的問題，這時候我們就需要用ONVIF Device Test Tool這個工具來幫忙查看問題的所在。下面簡單介紹一下登陸的幾個部分[3]。

1）根據(jù)IPC的不同其登陸的代碼也有所不同主要體現(xiàn)在其是否需要獲取權(quán)限，無論是否需要獲取權(quán)限，最重要的部分是：通過onvif協(xié)議中的soap_call___tds__GetCapabilities函數(shù)我們可以獲得gcsr結(jié)構(gòu)體中的信息保存到設(shè)備中，其中最主要的是信息如IPC是否支持媒體或者是云臺等信息，并且獲得媒體的url。

2）在成功獲得IPC的各種Capabilities的基礎(chǔ)上，可以進(jìn)行獲取配置文件。通過soap_call___trt__GetProfiles函數(shù)我們可以得到struct_trt__GetProfilesResponse結(jié)構(gòu)體中的信息數(shù)據(jù)。

2.2 獲取媒體流的uri

Uri是統(tǒng)一資源標(biāo)識符（Uniform Resource Identifier）它不僅對于視頻的播放很正要，我們還可以通過VLC播放器播放該uri的視頻信息，以此確認(rèn)視頻斷開的原因來自于哪一方，提高在NVR上面視頻傳輸?shù)目煽啃院蛯?shí)時性[4]。

2.3 rtsp簡單的交互式消息

RTSP是基于文本的協(xié)議，采用ISO 10646字符集，使用UTF－8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基于文本的協(xié)議使以自描述方式增加可選參數(shù)更容易。

請求包括方法、方法作用于其上的對象和進(jìn)一步描述方法的參數(shù)。方法也可設(shè)計(jì)為在服務(wù)器端只需要少量或不需要狀態(tài)維護(hù)[5]。

1）第一步：查詢服務(wù)器端可用方法并且建立TCP的socket的連接

設(shè)備－＞IPC:OPTION request

IPC－＞設(shè)備:OPTION response

2）第二步：得到媒體描述信息

設(shè)備－＞IPC:DESCRIBE request

IPC－＞設(shè)備:DESCRIBE response

3）第三步：指定流式媒體的傳輸機(jī)制

設(shè)備－＞IPC:SETUP request

IPC－＞設(shè)備:SETUP response

4）第四步：請求開始傳送數(shù)據(jù)

設(shè)備－＞IPC:PLAY request

IPC－＞設(shè)備:PLAY response

5）第五步：數(shù)據(jù)傳送播放中

IPC－＞設(shè)備:發(fā)送流媒體數(shù)據(jù)

6）第六步：關(guān)閉會話，退出

設(shè)備－＞IPC:TEARDOWN request

IPC－＞設(shè)備:TEARDOWN response

上述的過程只是標(biāo)準(zhǔn)的、友好的rtsp流程，但實(shí)際的需求中并不一定按此過程。其中第三和第四步是必需的！第一步，只要服務(wù)器客戶端約定好，有哪些方法可用，則option請求可以不要。第二步，如果我們有其他途徑得到媒體初始化描述信息（比如http請求等等），則我們也不需要通過rtsp中的describe請求來完成。

2.4 H.264媒體傳輸

IPC的數(shù)據(jù)是經(jīng)過H264進(jìn)行編碼，為了可以在RTP上面進(jìn)行傳輸，是需要把編碼后的數(shù)據(jù)放到RTP包中進(jìn)行傳輸?shù)囊簿褪菍.264視頻中剝離出每個NALU，在每個NALU前添加相應(yīng)的RTP包頭，然后將包含RTP包頭和NALU的數(shù)據(jù)包發(fā)送出去。H.264媒體數(shù)據(jù)通過RTP的發(fā)送過程如下，接收過程相反：RTP協(xié)議從上層接收流媒體信息碼流H.264，封裝成RTP數(shù)據(jù)包通過UDP協(xié)議發(fā)送到客戶端，客戶端將RTP數(shù)據(jù)包中NALU進(jìn)行解析讓后放入解碼器中進(jìn)行解碼即可對媒體流進(jìn)行播放了。

3 結(jié)論

文中是在onvif 2.3.0協(xié)議基礎(chǔ)上進(jìn)行架構(gòu)的，在調(diào)試過程中運(yùn)用onvif測試工具12.12對于NVR和IPC互通中出現(xiàn)的問題進(jìn)行分析。根據(jù)NVR設(shè)備最終的顯示的圖像畫面說明了關(guān)于NVR和IPC的媒體流傳輸問題，通過ONVIF協(xié)議就可以完成。文中證明了ONVIF協(xié)議對于實(shí)現(xiàn)NVR和IPC媒體流傳輸?shù)挠行浴?/p>

[1]潘熠.視頻錄像在監(jiān)控系統(tǒng)的發(fā)展趨勢[J].中國安防，2009（5）:53-55.PAN Yi.Video footage in the monitoring and control system[J].The Development Trend of China′s Security，2009（5）:53-55.

[2]楊劍鋒.多通道數(shù)字硬盤錄像機(jī)的設(shè)計(jì)與實(shí)現(xiàn)[D].遼寧：大連理工，2009.

[3]楊建全，梁華，王成友.視頻監(jiān)控技術(shù)的發(fā)展與現(xiàn)狀[J].現(xiàn)代電子技術(shù)，2006（21）：11-13.YANG Jian-quan，lIANG Hua，WANG Cheng-you.Video monitoring technology development and the status quo of[J].Journal of Modern Clectronic Technology，2006（21）:11-13.

[4]西剎子.安防天下—智能網(wǎng)絡(luò)視頻監(jiān)控技術(shù)詳解與實(shí)踐[C].北京：清華大學(xué)出版社，2010.

[5]王永嘉.監(jiān)控系統(tǒng)-客戶端設(shè)計(jì)與實(shí)現(xiàn)[D].浙江：浙江大學(xué)，2009.

[6]尹磊.多媒體終端的設(shè)計(jì)與實(shí)現(xiàn)[J].科學(xué)技術(shù)與工程，2010（22）:33-34.YIN Lei.The design and implementation of multimedia terminal[J].Science，Technology and Engineering，2010（22）:33-34.