高速公路監控中心視頻方案研究

李翔

（中遠海運科技股份有限公司 上海市 200135）

視頻監控，作為遠程監控最基本、最直觀的方式，得到了廣泛的應用，無論在川流不息的高速公路、人聲鼎沸的街邊路口，還是戒備森嚴的科研院所，到處都有攝像頭的身影。

傳統的高速公路視頻監控方案多以C/S 架構為基礎，通過客戶端與服務端進行連接，實現攝像頭的控制，視頻的查看以及錄像的調閱等操作，此種方式雖功能強大卻需要為每臺終端安裝客戶端，且客戶端對終端的操作系統、硬件配置等有一定要求，無法實現方便的即時視頻查看。此外，隨著物聯網的廣泛應用，基于移動的視頻直播、視頻查看等也逐漸被大眾所接受，相關的應用需求也越來越多。

隨著全國高速公路視頻云聯網的逐步鋪開，各地高速公路管理單位均面臨著視頻數據聯網和共享的需求，省級高速公路視頻資源需要全部匯聚分發，并與部級監控平臺實現無縫對接。

本文通過對視頻數據采集傳輸的各個流程進行簡要介紹，并對目前較為主流的實時視頻傳輸方案進行研究，結合高速公路視頻云聯網技術要求，針對不同的使用場景提出較為合理的視頻采集、分發、傳輸以及播放方案。

1 視頻數據的采集與分發

1.1 視頻采集

目前，視頻數據多采用數字方式進行采集、傳輸和存儲。前端數字攝像機采集視頻信號后，以標準視頻格式（如主流的H.264 標準）或廠商私有格式進行編碼壓縮，視頻流數據以推（攝像頭主動發送）或拉（后端服務器向攝像頭請求）的方式傳送至位于監控中心視頻服務器中。

對于無法提供標準格式的數字視頻攝像機，可通過開發軟件，以設備SDK 調用的方式實時獲取視頻流數據，再將其以標準視頻流協議格式封裝，傳輸至服務器。

而較老的模擬視頻設備，則可采用視頻采集卡等硬件設備，實時將模擬視頻信號轉換成數字視頻信號進行傳輸。

隨著物聯網的普及，移動視頻采集也得到了越來越廣泛的應用。此外，部分高速公路管理部門配備了移動指揮車，由現場攝像頭采集的實時視頻通過無線網絡傳輸至控制大廳。對于不提供標準視頻流協議的攝像頭和移動設備，通常采用系統SDK 來進行交互，獲取視頻數據，經過標準協議編碼封裝后傳輸至服務器。

在《全國高速公路視頻云聯網技術要求》中，定義了“視頻上云網關”的前置應用設備。通過網關，適配各個廠家的私有協議，將采集到的視頻以“統一、標準”的視頻格式推送至云平臺。

1.2 視頻分發

視頻流數據到達視頻服務器后，可進行存儲及分發。目前視頻分發采用的方式有如下幾種：

1.2.1 組播方式

視頻組播方式是采用IP 組播（multicast），將視頻流數據封裝在組播數據包中進行傳輸和分發的一種技術。

相較于單播（unicast）與廣播（broadcast）方式而言，組播方式解決了數據傳輸效率低的問題。當用戶請求特定信息時，組播源僅向單一地址發送一次信息，相關網絡設備（路由器、交換機等）借助組播路由協議為組播數據包建立樹型路由，被傳遞的信息在盡可能遠的分叉路口才開始復制和分發。故在組播方式中，在線客戶端數量的增長對服務端基本沒有壓力。

但是，組播方式自身也存在一定的局限性：由于需要相關網絡設備的支持，組播一般被應用于局域網內，組播數據包無法穿透防火墻，也就無法為Internet 上的用戶提供服務。此外，組播是基于無連接的UDP 協議，在網絡條件較差的環境中，阻塞控制、延遲控制等相關問題均無法獲得滿意的效果。

1.2.2 流媒體服務器方式

流媒體服務器方式的視頻分發是流媒體服務器在獲取到原始視頻流后，以相應的流媒體傳輸協議重新封裝視頻流數據，然后將數據以TCP或者UDP方式點對點（即單播方式，unicast）傳輸至客戶端。

由于支持TCP 協議，在網絡較差的環境中，系統可以較好地進行阻塞控制、延遲控制等調節，保證視頻的傳輸質量，此外，部分實時視頻協議也支持跨防火墻進行傳輸，為Internet 上的視頻發布提供了支持。

此外，由于視頻數據流是通過服務器進行中轉，視頻格式轉換、分辨率、碼率等的調整均可在服務器端進行。

由于所有的客戶端均直接與流媒體服務器直接連接，相較于組播方式而言，此種方案對服務器的性能要求較高。

兩種方式的比較參見表1。

表1

根據視頻上云的要求，視頻流經采集并在省級云平臺匯聚后，需要通過互聯網接入部級云平臺。故省部級云平臺直接，需要采用流媒體方式傳輸視頻。而在省級云平臺內部，流媒體方式與組播方式均可采用。

1.3 常見視頻流傳輸協議

目前，行業中使用較為普遍的視頻流傳輸協議有如下幾種：

1.3.1 RTSP

實時流協議（Real Time Streaming Protocol，RTSP）是一種網絡應用協議，用以控制流媒體服務器。該協議創建和控制終端之間的媒體會話，媒體服務器的客戶端使用RTSP 協議發送VCR 命令（如播放、暫停等），實時控制從服務器到客戶端（視頻點播）或從客戶端到服務器（語音錄音）的媒體流。

流數據本身的傳輸不是RTSP 的任務。大多數RTSP 服務器使用實時傳輸協議（RTP）和實時控制協議（RTCP）結合媒體流傳輸。由于RTP 協議是基于UDP 構建，RTSP 一般用于在局域網等網絡條件較好的環境中進行視頻流傳輸。

1.3.2 RTMP

RTMP 協議是Real Time Message Protocol(實時信息傳輸協議)的縮寫，它是由Macromedia 公司（后被Adobe 公司收購）提出的一種應用層的協議，用來解決多媒體數據傳輸流的多路復用（Multiplexing）和分包（packetizing）的問題。

RTMP 基于TCP 協議構建，在此協議中，通訊雙方建立了一個持續性的低延遲通信通路。為了將視頻流暢、高效地傳輸，RTMP將視頻流分割成片段（fragments）,而片段的大小通常由服務端和客戶端商討來確定。通常，對于音頻內容，片段的大小為64 字節，而對于視頻以及其他內容則為128 字節。切片之后，來自不同流的片段會在一個長連接中交叉傳輸。

1.3.3 HLS

HTTP Live Streaming（HLS）是一個由蘋果公司提出的基于HTTP 的流媒體網絡傳輸協議。相對于常見的流媒體直播協議（如RTMP 協議、RTSP 協議、MMS 協議等），HLS 直播最大的不同在于，直播客戶端獲取到的并不是一個完整的數據流。HLS 協議在服務器端將直播數據流存儲為連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷下載并播放這些小文件。因為服務器端總是會將最新的直播數據生成新的小文件，這樣客戶端只需不斷按順序播放從服務器獲取到的文件，就實現了流的實時播放。

在一個流媒體會話開始時，客戶端會下載一個包含元數據的extended M3U (m3u8) playlist 文件，用于尋找可用的媒體流。在播放過程中，客戶端可以選擇從其他備用源中以不同的速率下載同樣的資源，來適應變化的網絡速率。受益于分段文件時長較短的特點，客戶端可以很快的選擇和切換碼率，保障播放的連續性。

由于HLS 只請求基本的HTTP 報文，與實時傳輸協議（RTP）不同，HLS 可以穿過任何允許HTTP 數據通過的防火墻或者代理服務器，也能使用內容分發網絡(CDN)來傳輸。

由于HLS的技術特點，它的延遲會高于普通的流媒體直播協議，故對于實時性要求非常高的場合，不采用HLS 方式。

1.3.4 HTTP FLV Live Streaming

基于HTTP 的FLV 視頻流則是Adobe 公司的標準，通過將視頻流數據以H.264 進行編碼后，以HTTP 包的格式進行網絡傳輸。其實現與HLS 類似。目前大量的視頻網站均采用此種方式進行視頻的直播和點播。

1.3.5 WebRTC

WebRTC(Web Real-Time Communication)協議不僅僅用于傳輸視頻，此協議支持通過簡單API 傳輸視頻、語音以及通用數據。此協議基于瀏覽器，且主流瀏覽器均支持，具有較強的跨平臺能力。此外，協議支持STUN、ICE、TURN 等NAT 和防火墻穿透技術。

WebRTC 的傳輸設計基于P2P，在復雜網絡環境中，故傳輸質量難以得到保證，需要采用CDN 技術等來輔助提升傳輸體驗。也正是由于其P2P 的傳輸特點，對于視頻監控這種1 對多的場景，需要借助服務端方案。

根據各協議的特點，在不同的應用場景中，應選擇不同的協議來保證視頻傳輸效果、服務器壓力等各方面的相對均衡，以期在有限的成本下獲取最佳的效果。在視頻聯網的技術要求中，省級云平臺采用RTMP 協議向部級云平臺推送低碼率實時視頻，同時，省級監控平臺需要提供HTTP-FLV、HLS 等協議支持，便于部級云平臺調閱所有攝像機的高碼率實時視頻。

1.4 視頻轉碼

根據高速公路視頻云聯網要求，各路監控視頻需要以不同碼率和協議進行傳輸分發。這就涉及到了視頻的轉碼問題。結合目前公有云技術的發展，視頻轉碼可采用租用公有云計算資源的“云端轉碼”和使用自有硬件資源的“本地轉碼”兩種方式。

“本地轉碼”方式前期建設資金投入較高，但運維期間投入費用較低，結合機電設備的使用壽命周期，本地轉碼方案的經濟效益要高于云端轉碼[1]。同時，目前的監控中心，大都基于服務器+IPSAN 的架構，這種以流媒體服務器為核心的架構，提供了前所未有的流媒體轉發能力[2]，足以滿足視頻聯網規范中對于視頻轉碼的需求。

2 視頻的展示

2.1 B/S架構下的視頻展示

2.1.1 視頻播放

在IE 瀏覽器“一統江湖”的時代，在瀏覽器中查看視頻是通過ActiveX 控件來實現的。因為ActiveX 極易被黑客利用，目前IE瀏覽器對于ActiveX 控件的管控非常嚴格，特別是對于沒有數字簽名的控件，在默認安全級別下將無法安裝。因此，控件的部署變得較為困難。此外，由于IE 的穩定性欠佳，瀏覽器常常被ActiveX控件影響而失去響應。

隨著HTML5 技術的廣泛普及，各主流瀏覽器已經基本完成了flv 及mp4 視頻的原生播放支持。為此，可以采用基于rtmp 方式的flv 方式、基于HTTP 方式的flv 方式或者hls 方式進行視頻展示。

對于原生支持hls 的瀏覽器，可以直接以HTML5 的＜video＞標簽來播放hls 視頻流；對于無法提供原生支持的瀏覽器，可以通過開發相應的flash 播放器組件來播放視頻。目前，網絡上存在開源免費與收費的各種flash視頻播放器，均可實現實時視頻流的播放。

依靠目前主流瀏覽器JavaScript 引擎性能的大幅進步，對于http flv streaming 方式的實時視頻，除了通過flash 播放器方式來實現播放以外，還可以通過JavaScript 腳本，將視頻轉換成html5 視頻標簽支持的格式，實現瀏覽器直接播放。2021年1月1日開始， FlashPlayer 的生命周期正式結束。對于實時性要求較高的監控場景，基于RTMP 的視頻流是唯一的選擇。為此，可以考慮使用WebRTC的方式進行數據傳輸。

2.1.2 視頻墻

在高速公路視頻監控領域，還存在一類典型的視頻應用：視頻墻，即以多畫面的形式在同一界面上同時展示不同來源的視頻。在基于C/S 的架構中，此種應用不存在任何問題，僅需將多個視頻播放控件放在一個界面即可。但在B/S 架構下，多路flash 視頻同時播放會對瀏覽器帶來巨大的運行壓力，并最終導致瀏覽器失去響應。

為此，在并發視頻數量較大，視頻碼率較高的場景中，可以考慮兩種方案：

（1）后端視頻合成+前臺熱區操作。在此方案中，需要后端系統（服務器或者視頻合成硬件）等直接將需要集中展示的各路視頻合成為一路視頻，然后傳輸至前端展示。前端采用flash 播放器或者原生視頻展示，同時在合成視頻的各自視頻區域疊加相應的操作熱區，當用戶點擊相應熱區時將視頻源切換至對應的單路視頻。

（2）前端直接多視頻展示。考慮視頻墻是大批量視頻的監控，其對于視頻實時性的要求較單路監控視頻而言較低；而視頻播放的原理，是從視頻流中解碼出視頻畫面，并繪制到用戶界面上。

依托于開源的力量，目前已經存在此類的解決方案(如jsmpeg)，通過websocket，后臺服務器將視頻流傳輸至前端，再由JavaScript 引擎進行視頻的解碼，通過WebGL & Canvas2D 將圖像繪制到屏幕中。由于WebGL & Canvas2D 在文檔對象模型(DOM)樹中是一個div 對象，通過JavaScript 很容易實現點擊選擇的操作。

2.1.3 控制指令交互

在傳統的B/S 架構中，瀏覽器在向服務器請求完數據后，連接即被斷開，當需要進行數據交換時需要重新建立連接。而在視頻監控應用中，類似攝像頭PTZ 操作等需要非常短傳輸延遲，以期獲得迅速的反饋。為此，需要在瀏覽器與服務器之間建立類似TCP的長連接。

WebSocket 通過在通信兩端建立基于TCP 連接的雙向通道，實現在支持HTML5 的瀏覽器客戶端與服務端之間雙全工通信的網絡技術。在WebSocket 通信實現過程中，當客戶端向服務器發出建立連接請求后，服務器端應答建立連接，這時通信協議由 HTTP 協議升級成為WebSocket 協議，兩端就可以直接交換數據，該雙向通道會持續保持連接，服務器端的最新數據能夠實時推送給客戶端，實現實時通信[3]。

除了WebSocket，還可以采用WebRTC 來傳輸控制指令，實現多種數據的單一通道傳輸。

視頻云聯網技術要求中，對于控制指令通道的要求是采用基于HTTPS 的控制接口，通信報文采用json 格式。由于部級云平臺對于設備的控制實時性要求不高，在保證網絡延遲的前提下，采用HTTPS 協議來傳輸控制指令能夠滿足需求。同時，采用HTTP/2 的長連接技術，也有助于降低整體的控制指令交互延遲。

2.2 移動架構下的視頻展示

對于采用原生代碼開發的APP，可采用各種現有的視頻控件來實現視頻的播放。對于畫面延遲性要求較高的應用，一般采用rtmp協議或者私有化UDP 協議進行視頻的傳輸。

對于HTML5 混合編程的APP，可參考B/S 架構下的視頻播放章節中的方案，采用已被iOS/Android 平臺原生支持的MP4 格式視頻，在WebView 中進行直接展示。此方案的缺點是延遲較大，如果使用 RTMP 或者 HTTP-FLV，延遲會在 1 秒到 3 秒之間，如果用 HLS 延遲會大于 8 秒甚至 10 秒[4]。故在低延遲場景下，可以考慮采用WebRTC 協議來傳輸實時視頻流。由于此協議基于P2P，需要自行開發或采用第三方的解決方案實現流媒體服務。

3 結語

本文通過對主流視頻流媒體傳輸協議的分析，結合B/S 架構以及移動應用環境的特點，提出了針對不同環境的視頻監控解決方案。結合目前全國高速公路視頻聯網的要求，對視頻的采集方式，視頻傳輸的協議要求等均進行了闡述。隨著全國高速公路聯網工作的鋪開，各地的高速高速公路監控將變得更加可視化和智能化，這不僅為全國高速公路的統一管理提供了有力保證，也為人民群眾的出行提供了更大的便利。