韓濱旭 沈玉玲 王子萍

1(上海電氣集團(tuán)股份有限公司中央研究院 上海 200070) 2(上海電氣自動(dòng)化設(shè)計(jì)研究所有限公司 上海 200023)

0 引 言

視頻監(jiān)控技術(shù)從最早的模擬視頻發(fā)展到數(shù)字視頻直至今天的網(wǎng)絡(luò)視頻技術(shù)經(jīng)歷了多個(gè)發(fā)展階段。網(wǎng)絡(luò)視頻是結(jié)合多媒體、計(jì)算機(jī)網(wǎng)絡(luò)、人工智能以及工業(yè)控制等多種技術(shù)的綜合應(yīng)用[1]。視頻監(jiān)控系統(tǒng)市場的日益擴(kuò)大也使網(wǎng)絡(luò)視頻技術(shù)的需求持續(xù)增長，各種網(wǎng)絡(luò)視頻設(shè)備也如雨后春筍般出現(xiàn)在各種視頻監(jiān)控系統(tǒng)中。因?yàn)椴煌膹S商使用的通信協(xié)議不一致，不同廠商的視頻設(shè)備接入給網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)帶來了難題。2011年12月，GB/T 28181 標(biāo)準(zhǔn)正式將SIP 協(xié)議作為視頻監(jiān)控聯(lián)網(wǎng)的整體通信過程與組網(wǎng)架構(gòu)的標(biāo)準(zhǔn)協(xié)議[2]。然而，在很多應(yīng)用情況下，尤其是國外的視頻設(shè)備廠家生產(chǎn)的設(shè)備并不是全部支持SIP協(xié)議。在2008 年由SONY 等多家大型視頻行業(yè)相關(guān)企業(yè)創(chuàng)建了ONVIF 組織，該組織制訂的協(xié)議標(biāo)準(zhǔn)目標(biāo)是解決視頻設(shè)備互聯(lián)互通等問題，重點(diǎn)關(guān)注客戶端與服務(wù)端的接口通信[3]。2012年在視頻監(jiān)控刮起了一股互聯(lián)互通標(biāo)準(zhǔn)的春風(fēng)，從公安部推行國家標(biāo)準(zhǔn)GB28181再到各地方、各行業(yè)推行DB33等地方標(biāo)準(zhǔn)，強(qiáng)制要求各廠家產(chǎn)品實(shí)現(xiàn)對GB28181、ONVIF等標(biāo)準(zhǔn)協(xié)議的支持，給各種視頻監(jiān)控系統(tǒng)項(xiàng)目建設(shè)提供了互聯(lián)互通的技術(shù)標(biāo)準(zhǔn)[4]。

GB/T 28181與ONVIF協(xié)議的結(jié)合可以同時(shí)發(fā)揮兩者的優(yōu)勢，在GB/T 28181下發(fā)揮ONVIF協(xié)議設(shè)備發(fā)現(xiàn)及設(shè)備信息獲取的優(yōu)勢。ONVIF 協(xié)議和GB28181 標(biāo)準(zhǔn)對媒體流的播放流程都做出了規(guī)定，然而兩種協(xié)議下媒體播放請求的流程并不一致，使得媒體服務(wù)器在媒體播放的實(shí)現(xiàn)上發(fā)生了沖突[5]。ONVIF協(xié)議如何與GB28181標(biāo)準(zhǔn)協(xié)同合作是在很多應(yīng)用情景中，例如多級平臺(tái)或者復(fù)雜系統(tǒng)，需要解決的問題。舉例說明一種特殊情況，客戶端呼叫SIP服務(wù)器，請求通過解碼器播放視頻流而解碼器作為設(shè)備只支持ONVIF協(xié)議。本文通過使用RTSP申請視頻流的方式代替媒體流上傳的方式解決這一兼容性的問題。

1 GB28181媒體流播放流程分析

GB28181標(biāo)準(zhǔn)下點(diǎn)播視頻流的過程通過SIP 協(xié)議的INVITE，ACK， INFO，BYE 類型消息來完成。INVITE 消息的內(nèi)容是一個(gè)SDP 消息體，該消息體描述了要請求的媒體發(fā)送者信息[5]。GB28181中描述了客戶端作為命令發(fā)起者與媒體流接收者的信令流程以及第三方呼叫，其他設(shè)備作為媒體流接受者的信令流程。可以發(fā)現(xiàn)其中并沒有對客戶端呼叫且其他設(shè)備作為媒體流接受者的信令流程進(jìn)行定義。如圖1所示，對客戶端呼叫且客戶端接受媒體流的實(shí)時(shí)視頻點(diǎn)播流程分析。

圖1 GB28181中由客戶端發(fā)起播放視頻流的流程示意圖[2]

如圖1所示，從第2步到第7步是視頻服務(wù)器溝通媒體服務(wù)器與前端攝像設(shè)備的過程，其目的是使媒體服務(wù)器與前端設(shè)備交換信息，之后建立前端設(shè)備向媒體服務(wù)器發(fā)送實(shí)時(shí)媒體流的通道。而媒體流發(fā)送者與媒體流接受者設(shè)備在引言中所述的情況下均不支持GB28181，第4步到第5步就無法實(shí)現(xiàn)從前端設(shè)備獲取信息，同時(shí)視頻服務(wù)器也無法獲取媒體流接收者即解碼器信息，媒體服務(wù)器也就無法從視頻服務(wù)器獲取對應(yīng)的解碼器信息。

2 ONVIF媒體流播放流程分析

如前所述，ONVIF與GB28181的結(jié)合主要需要突出兩者的優(yōu)勢，而ONVIF的優(yōu)勢之一就在于發(fā)現(xiàn)設(shè)備與獲得設(shè)備信息。ONVIF 很大程度上支持現(xiàn)有的標(biāo)準(zhǔn)，它的目標(biāo)是實(shí)現(xiàn)不同設(shè)備的互聯(lián)互通，而不是定義全新的標(biāo)準(zhǔn)?；谝陨显瓌t，ONVIF 的設(shè)備發(fā)現(xiàn)采用現(xiàn)有的萬維網(wǎng)動(dòng)態(tài)發(fā)現(xiàn)協(xié)議WS-Discovery[6]。通過ONVIF的發(fā)現(xiàn)設(shè)備和獲得設(shè)備信息取得支持ONVIF協(xié)議的設(shè)備信息，且因?yàn)镺NVIF與GB28181都是通過XML在服務(wù)器中進(jìn)行解析則可以很好的定義兩者之間XML的轉(zhuǎn)換。具體如何獲得ONVIF設(shè)備的設(shè)備信息如圖2所示。

圖2 ONVIF中客戶端發(fā)起實(shí)時(shí)媒體流播放的流程示意圖[3]

在視頻服務(wù)器啟動(dòng)時(shí)，可以通過ONVIF服務(wù)組播發(fā)送Probe報(bào)文發(fā)現(xiàn)前端設(shè)備，并根據(jù)獲得的設(shè)備列表根據(jù)設(shè)備類型通過GetProfiles獲得設(shè)備的媒體信息。那么如何將這些媒體信息交互給媒體服務(wù)器，并過視頻服務(wù)器將這些信息共享到參與媒體流播放的設(shè)備就需要GB28181的協(xié)同配合。

3 ONVIF與GB28181的協(xié)同配合流程

視頻服務(wù)器通過ONVIF服務(wù)獲得所有ONVIF設(shè)備信息是并行的，即所有GetProfiles是ONVIF協(xié)議棧經(jīng)過處理后啟動(dòng)線程池并行的使用ONVIF服務(wù)進(jìn)行發(fā)送。之后并發(fā)的接收設(shè)備端傳回的信息，為方便備份與處理首先應(yīng)該將信息存儲(chǔ)進(jìn)入數(shù)據(jù)庫與內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)相映射的表中。

在視頻服務(wù)器獲取設(shè)備信息的同時(shí)，媒體服務(wù)器發(fā)送SIP協(xié)議總的Catalog指令到視頻服務(wù)器獲取視頻服務(wù)器通過ONVIF協(xié)議獲得的設(shè)備信息，設(shè)備的URL信息存放在Catalog報(bào)文內(nèi)容中的PlayUrl標(biāo)簽中。ONVIF 的標(biāo)準(zhǔn)接口可以解決非標(biāo)準(zhǔn)化網(wǎng)絡(luò)攝像機(jī)通過RTSP 流媒體協(xié)議解決接入問題，也為使用RTSP控制媒體流奠定了基礎(chǔ)[7]。

如圖3所示，車站的解碼器在第7步使用RTSP協(xié)議從編碼器獲取媒體流，而設(shè)備信息的獲取均是通過ONVIF信息向兩個(gè)設(shè)備獲取并通過視頻服務(wù)器進(jìn)行交換。如果參考此流程，解碼器同樣可以使用RTSP從媒體服務(wù)器獲取媒體流，而媒體服務(wù)器同理可以使用RTSP從媒體流發(fā)送者獲取媒體流。

圖3 車站域內(nèi)視頻流通信流程[8]

如圖4所示，相關(guān)流程說明如下：

1) 客戶端向視頻信令服務(wù)器發(fā)送SIP協(xié)議中的INVITE命令，請求中附帶SDP消息體，里面包含了媒體流發(fā)送者也就是前端設(shè)備的ID以及地址等信息。

2) 視頻服務(wù)器通過ONVIF命令ConfigReceiver請求將媒體流發(fā)送者信息、媒體服務(wù)器信息以及使用的解碼器通道信息遞送給解碼器。

3) 解碼器通過得到的媒體流發(fā)送者信息及自身信息通過RTSP發(fā)送到媒體服務(wù)器。

4) 媒體服務(wù)器通過媒體流發(fā)送者信息在已通過前述Catalog命令得到的設(shè)備信息表中查詢相關(guān)的URL并通過RTSP請求媒體流發(fā)送者的媒體流。

5) 解碼器收到媒體流發(fā)送的媒體流后向視頻服務(wù)器回復(fù)第2步的ONVIF的響應(yīng)。

6) 視頻服務(wù)器得到ONVIF響應(yīng)后回復(fù)客戶端第1步INVITE請求的SIP響應(yīng)200OK。

圖4 GB28181與ONVIF配合流程

4 視頻服務(wù)器的內(nèi)部調(diào)度

GB/T 28181-2011通過引入國際多媒體通信SIP協(xié)議及通信機(jī)制來規(guī)劃系統(tǒng)整體信令組網(wǎng)架構(gòu)，在此之上定制了專有系統(tǒng)控制描述協(xié)議MANSCDP，從而實(shí)現(xiàn)信令的互聯(lián)互通[9]。

視頻服務(wù)器使用JAIN SIP及ONVIF-WS-CLIENT的JAVA框架構(gòu)建GB28181與ONVIF的底層服務(wù)。在兩個(gè)服務(wù)之上構(gòu)建協(xié)議棧，之后采用監(jiān)聽者設(shè)計(jì)模式來實(shí)現(xiàn)兩者之間的交互。

如圖5所示，SIP與ONVIF服務(wù)均會(huì)有對應(yīng)的監(jiān)聽者對象，那么在服務(wù)判斷下一步流程需要另一方的服務(wù)時(shí)，例如客戶端發(fā)起實(shí)時(shí)視頻流調(diào)用的請求，只要觸發(fā)Update()方法進(jìn)入觀察者就可以。在觀察者內(nèi)部實(shí)現(xiàn)對應(yīng)協(xié)議的轉(zhuǎn)化，并調(diào)用相應(yīng)的另一種服務(wù)發(fā)出即可，這種模式可以很好地完成兩者之間的數(shù)據(jù)交換。而不是通過內(nèi)部TCP通信的方式或者進(jìn)程間通信，這樣可以滿足視頻服務(wù)真正兼容兩個(gè)協(xié)議。而RTSP的使用，也避免了GB28181流程中媒體流推送有可能出現(xiàn)卡頓的現(xiàn)象，因?yàn)橐姑襟w流主動(dòng)推送則會(huì)優(yōu)先選用UDP協(xié)議，而當(dāng)網(wǎng)絡(luò)傳輸能力不能滿足實(shí)時(shí)傳輸要求時(shí)，被丟棄的數(shù)據(jù)包將不被重復(fù)傳送就會(huì)出現(xiàn)卡頓現(xiàn)象[10]。使用RTSP并通過TCP建立連接就可以有效地避免這種數(shù)據(jù)包丟棄不被重復(fù)傳送的問題。

圖5 視頻服務(wù)器使用觀察者模式內(nèi)部結(jié)構(gòu)

5 結(jié) 語

通過上述的方法可以發(fā)揮GB28181與ONVIF兩種協(xié)議的優(yōu)勢。使用觀察者模式的視頻服務(wù)器可以很好地解決兩種服務(wù)之間的交互保證了整個(gè)流程的一致性與完整性。使用RTSP相比GB28181的點(diǎn)播流程節(jié)約了不少溝通過程，更高效地實(shí)現(xiàn)了媒體流的播放并且避免了丟棄數(shù)據(jù)包不被重復(fù)傳送問題的發(fā)生。