webrtc在民用安防行業中的應用

5 人贊了文章

相似點

webrtc是互聯網行業中流媒體技術的集大成者，涵蓋了音視頻採集、媒體處理、編碼、p2p、網路發送到網路接收、解碼。普遍用於直播、音視頻聊天、視頻會議，可以讓沒有音視頻開發經驗的人也可以輕鬆開發音視頻通訊軟體。

傳統安防視頻監控行業也是基於音視頻流媒體技術做開發。在設備端，晶元負責音視頻採集和編碼，嵌入式上層應用模塊根據通訊協議進行網路傳輸，客戶端（PC、移動端）中有netsdk網路接收、playsdk做解碼顯示。

痛點

安防行業在逐漸向民用發展，隨著移動互聯網的到來網路環境也由區域網轉向窄帶公網。這幾年逐漸遇到如下痛點：

1. P2P

傳統方式下，先走P2P，P2P不成功再走轉發。這是串列的方式，等轉發出圖要過5、6秒。P2P大都用UDP。UDP容易丟包且亂序，從而導致圖像卡頓流暢性差。傳統P2P用戶體驗非常差，用戶投訴很多，不得已，很多安防廠家只能走純伺服器轉發的方式，但云伺服器的費用是筆巨大的開支。以某安防公司為例，它一年生產1000萬台家用攝像頭。假設千分之一的設備同時在線，設備的平均碼率是1Mbps，雲伺服器費用按50Mbps 10W元/年，每年新增的設備轉發費用是10000000/1000/50*10W元=2000W元，這還不包括體量更龐大的存量設備。每年在原來基礎上再增加2000W費用，一年辛苦賺的血汗錢都交給個雲服務公司了

2、回聲消除

回聲是因為語音對講時，聲音一邊在播放一邊在採集，採集時會把播放的聲音又採回去。在PC電腦時代，用的是耳機+麥克風，麥克風能採集到的耳機播放的聲音很小，所以回聲的問題不明顯。而到了移動互聯時代，手機端揚聲器大都是外置的，回聲就很大。

3、網頁客戶端

嵌入式設備和視頻綜合管理平台都支持B/S架構。B/S架構下觀看視頻是基於微軟的ocx控制項，但ocx越來越被人詬病：1、要安裝瀏覽器插件，調整瀏覽器安全級別，並允許active x控制項彈出。2、ocx控制項只能在windows環境下使用。3、最新的chrome、firefox版本不允許安裝ocx，連微軟新出的瀏覽器edge都不再支持ocx，IE的市場佔用率逐年下降。也有人用HLS在網頁上觀看視頻，但HLS的文件特性導致它不夠實時，不適用於實時預覽。特別是球機或帶雲台功能的搖頭機，用戶點一下方向鍵，要過5、6秒畫面才有反應，體驗極差。

優點

安防業的這些痛點，正是webrtc擅長的。

1. P2P

Webrtc中的p2p支持3種網路連接方式，區域網內直連、公網穿透、公網轉發。採用ICE框架，這3中網路連接是並發進行的。打個比方就是一條河上同時搭三座橋，哪條橋先搭好就直接通行。等優先順序高的橋搭好就把優先順序低的橋拆除（優先順序： 直連>穿透>轉發），並改用優先順序高的橋來通行。這樣可以保證即使穿透不成功的情況下走轉發，也能在1秒內出圖。每種方式會嘗試15秒，如果15秒內沒有聯通，就自動放棄。

Webrtc的UDP傳輸中，接收端的jitter buffer會做UDP包的亂序重組。在某時間閥值內發現一直沒等到某序號的包，就通過RTCP通知發送端重傳該序號的包。另外，發送端會根據發送的碼率做適度的流控。做了丟包重傳、亂序重組、流控的UDP有著不弱於TCP的傳輸效果，而且在窄帶公網（wifi、4G）下，UDP的傳輸效果優於TCP。

實踐證明，webrtc下基於UDP的p2p，具有出圖快、實時、流暢的優點。

P2P的過程如下：

由客戶端主動發起連接，兩端生成各自的sdp和candidate(公網映射地址和轉發地址需藉助stun和turn服務)。由信令服務交換雙方的sdp和candidate。Sdp協商成功後，就通過candidate並發的嘗試連接

NAT類型：1、完全圓錐型(FullConeNAT) 2、地址限制圓錐型（Address Restricted Cone NAT） 3、埠限制圓錐型(Port Restricted Cone NAT) 4、對稱型（Symmetric NAT）。 理論上3跟4、4跟4不能穿透。在國內普通家用wifi是NAT 3，移動4G是4，不能穿透。遺憾的是，在國內，4G網路是對稱型，普通家用網路是埠限制圓錐型，兩者不能相通。

2、回聲消除

webrtc的前身是GIPS，GIPS是回聲消除方面的權威。

3、chrome瀏覽器免插件訪問音視頻

webrtc跟chrome代碼同源(chromium)，所以chrome對webrtc的支持是順理成章的事情，firefox、edge、safari也都支持webrtc且會支持得越來越好。Webrtc給javascripe提供了介面調用。

後續webrtc會跟tensenflow結合，開發人員調用幾個js介面，就可以在chrome上看實時音視頻，並做人臉識別等功能。

另外webrtc的跨平台做得非常好，基本上在windows上跑通後，在linux、嵌入式、移動端上只要makefile一下就能正常運行了。嵌入式下出現的問題，都可以在windows上模擬出來（windows的visual stdio是宇宙第一IDE，對於問題定位調試和壓力測試非常方便）

難點

1. 設計場景差異

webrtc是為一對一的雙向音視頻通訊而設計，webrtc的demo（peerconnection）就是一個類似QQ視頻聊天的軟體。而安防監控是一對多（多客戶端）、多對多的（DVR、NVR多通道），視頻傳輸是單向的（只有設備到客戶端），語音可以是單向也可以雙向（對講）。要支持多對多，需要對代碼進行改造。

2、部分優秀功能不適用

如帶寬自適應，檢測到帶寬小時，自動降低幀率、碼率、解析度。但攝像頭可能多個客戶端在同時觀看，攝像頭本身可能還在TF卡本地錄像，不能因某個客戶端網路不好而影響到其他客戶端或錄像的圖像質量。對多的場景下，帶寬自適應不適用，或者說改造難度非常大（要麼對不同的客戶端編碼多份碼流，但這對晶元的cpu和內存要求非常高）。再一個功能是，當客戶端解碼出錯時會要求以當前正常解碼的幀為參考幀，讓設備端重新編碼，而不是強制I幀更加大網路擁堵。這功能在對多的場景下還是不太實用，而且要求編碼時帶幀ID（vp8、vp9支持，h264不支持幀ID）

3、資源投入大

涉及範圍廣，webrtc對安防業的改造，涉及到嵌入式設備端、PC端、移動端、伺服器端、網頁端，需要多部門協同。Webrtc本省代碼量也大。這些需要公司大量的資源投入

4、webrtc不支持h265編解碼

安防廠家越來越多使用h265，因為同等畫質下碼率是h264的一半。意味著網路傳輸只需更少的帶寬，同樣的硬碟容量存儲時間更長。但h265專利收費，webrtc不支持h265解碼。另外，google有推出自己的開源編解碼器vp9跟h265競爭，但vp9不被安防晶元支持。

5、對嵌入式不友好

webrtc對PC和移動端的支持已經很好，但在嵌入式端的進展不理想。沒有嵌入式，就沒有硬體產品。Google的那幫白鬍子老頭工程師估計都已財務自由，寫代碼更多出於自身興趣，偏重於演算法理論，對產品化和工程實踐關注較少。Webrtc中很多演算法對cpu要求很高，而嵌入式晶元性能大多比較差。如用於流媒體傳輸的SRTP用到AES加密演算法（個人覺得只對I幀的部分數據加密足矣），海思3516C下，加密的情況下客戶端預覽兩路2Mbps的碼流，設備端cpu佔用達到80%，在不做加密的情況下只佔40%。AES加密演算法，webrtc有對X86和nenon的彙編優化，但沒有嵌入式彙編優化。其他如回聲消除、帶寬自適應演算法都需要大量計算。webrtc中存在不少流媒體數據(rtp包)的內存拷貝。再一個webrtc用ninja編譯，而嵌入式下沒相應的gn工具, 需要手寫makefile， ninja是個坑人的玩意。另外對嵌入式下sleep的精確度考慮不足（嵌入式下sleep的精度很多是10-15毫秒， PC和移動端是1毫秒），易導致延時

解決方案

webrtc花了大量精力來實現音視頻採集、編解碼，但這些功能對於安防行業是雞肋。安防晶元和客戶端有成熟的h264、h265編解碼方案，包括硬軟編解碼。應把首尾兩端的採集編解碼裁剪，保留中間流程，採集和編解碼模塊平台差異性很大，這些模塊裁剪後也利於跨平台移植。可根據ninja文件中對各平台下的宏定義、需包含的文件、依賴的庫，來製作windows vs2015工程和linux makefile文件。有了linux makefile文件，再來寫嵌入式下的makefile和android下的Android.mk就比較容易。

通過建立多個peerconnection對象來支持多客戶端。通過多次AddStream來支持多通道（dvr、nvr），由stream_lable來標識不同的通道。

依據peerconnection demo（需熟悉win32底層GUI編程），來製作兩個庫，設備端的和客戶端的。設備端：把採集和編碼模塊裁剪，改成由外部傳入一幀幀的264數據，視頻改成只發送不接收。客戶端：把解碼模塊裁剪，改成接收到一幀h264後回調出去，外部playsdk解碼，視屏改成只接收不發送。

對於webrtc的應用，可以循序漸進。先從p2p著手，不做SRTP(為安全考慮，可對I幀的部分數據加密)，把回聲消除和帶寬自適應等cpu佔用高的功能先屏蔽掉。自定義媒體格式以支持265，客戶端用自己的playsdk來解碼。Chrome的支持可以先從伺服器、邊緣端（性能強的nvr，海思3531、3536）先支持，IPC端可以等新的性能更強的支持nenon的晶元方案（現有的3516C勉強也可以支持，路數少一點，碼率小一點）。可做成自適應，根據客戶端的uuid判斷客戶端類型。如果是chrome，就做SRTP。否則不做SRTP，由自己的playsdk解碼。

結語

傳統行業在擁抱互聯網時要有針對性有選擇的吸收。互聯網在改造傳統行業時應充分了解該行業的背景，與該行業的實際相結合。只有這樣，兩者才能真正融合，碰撞出火花，產出一個有創新性的產品和服務。

推薦閱讀：