可兼容GB28181與Onvif播放媒體流的視頻服務器

韓濱旭 沈玉玲 王子萍

1(上海電氣集團股份有限公司中央研究院 上海 200070) 2(上海電氣自動化設計研究所有限公司 上海 200023)

0 引 言

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

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

1 GB28181媒體流播放流程分析

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

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

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

2 ONVIF媒體流播放流程分析

如前所述，ONVIF與GB28181的結合主要需要突出兩者的優勢，而ONVIF的優勢之一就在于發現設備與獲得設備信息。ONVIF 很大程度上支持現有的標準，它的目標是實現不同設備的互聯互通，而不是定義全新的標準。基于以上原則，ONVIF 的設備發現采用現有的萬維網動態發現協議WS-Discovery[6]。通過ONVIF的發現設備和獲得設備信息取得支持ONVIF協議的設備信息，且因為ONVIF與GB28181都是通過XML在服務器中進行解析則可以很好的定義兩者之間XML的轉換。具體如何獲得ONVIF設備的設備信息如圖2所示。

圖2 ONVIF中客戶端發起實時媒體流播放的流程示意圖[3]

在視頻服務器啟動時，可以通過ONVIF服務組播發送Probe報文發現前端設備，并根據獲得的設備列表根據設備類型通過GetProfiles獲得設備的媒體信息。那么如何將這些媒體信息交互給媒體服務器，并過視頻服務器將這些信息共享到參與媒體流播放的設備就需要GB28181的協同配合。

3 ONVIF與GB28181的協同配合流程

視頻服務器通過ONVIF服務獲得所有ONVIF設備信息是并行的，即所有GetProfiles是ONVIF協議棧經過處理后啟動線程池并行的使用ONVIF服務進行發送。之后并發的接收設備端傳回的信息，為方便備份與處理首先應該將信息存儲進入數據庫與內存中的數據結構相映射的表中。

在視頻服務器獲取設備信息的同時，媒體服務器發送SIP協議總的Catalog指令到視頻服務器獲取視頻服務器通過ONVIF協議獲得的設備信息，設備的URL信息存放在Catalog報文內容中的PlayUrl標簽中。ONVIF 的標準接口可以解決非標準化網絡攝像機通過RTSP 流媒體協議解決接入問題，也為使用RTSP控制媒體流奠定了基礎[7]。

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

圖3 車站域內視頻流通信流程[8]

如圖4所示，相關流程說明如下：

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

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

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

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

5) 解碼器收到媒體流發送的媒體流后向視頻服務器回復第2步的ONVIF的響應。

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

圖4 GB28181與ONVIF配合流程

4 視頻服務器的內部調度

GB/T 28181-2011通過引入國際多媒體通信SIP協議及通信機制來規劃系統整體信令組網架構，在此之上定制了專有系統控制描述協議MANSCDP，從而實現信令的互聯互通[9]。

視頻服務器使用JAIN SIP及ONVIF-WS-CLIENT的JAVA框架構建GB28181與ONVIF的底層服務。在兩個服務之上構建協議棧，之后采用監聽者設計模式來實現兩者之間的交互。

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

圖5 視頻服務器使用觀察者模式內部結構

5 結 語

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