問題背景：
最近在SRS羣裏回答一些視頻監控設備上雲問題時，SRS開源作者讓我寫一篇文章介紹下視頻監控攝像頭的互聯網化實踐思路，很有幸畢業這幾年工作的大體方向都跟這個有關係，本篇就拋磚引玉說下視頻監控設備上雲的一些實踐和思考。
本篇文章核心內容大致分爲下面幾個部分，你可以選擇感興趣篇章閱讀，如果你對視頻監控行業比較陌生，可以看看以前這篇文章《從人類的第一次直播聊聊視頻監控行業》：
爲什麼監控攝像頭要上雲？互聯網化？
要上雲怎麼實踐？有哪些大坑需要填？
未來這塊還有哪些改進空間和期待？
如果你對本篇文章感興趣或者實際你們遇到了什麼開發問題，抑或這篇文章跟你的工作有關係想了解具體實現細節，由於新開公衆號不能留言，那就麻煩就在微信右下角點個在看或者直接加我個人微信，如果人多的話我後面花費十幾篇文章詳細介紹下視頻監控相關協議的方方面面：
視頻監控互聯網化改造的必要性：
視頻監控從目前來看分爲兩個大的方向：一個是傳統視頻監控，一個是消費類視頻監控。
前者其實很長一段時間跟大家關係都比較陌生，大家唯一能看到的就是掛在道路上的槍機、球機，一般都覺得這是震懾犯罪分子和維護公共安全，跟自己沒有很大關係。但是隨着這幾年AI和移動互聯網的發展，我們發現超市的攝像機能識別人臉還能識別VIP會員並進行刷臉支付，這是攝像頭和AI結合的案例；幼兒園的攝像頭能在手機上查看自家小孩在學校的學習情況和老師教育教學情況，這是攝像頭和直播技術在教育行業的落地；到蜂巢取快遞也是用攝像頭一掃二維碼就直接出貨拿走不用快遞員的再次確認，這是攝像頭利用圖像二維碼識別技術在物流行業的一次成功實踐，可以說攝像頭已經從傳統的震懾犯罪分子和社會公共安全領域拓展到和對傳統行業的改造上，這是最近幾年視頻監控行業快速發展的核心動力，已經從傳統的安防行業拓展到智慧城市，智能家居，智能物流各行各業。同時也從單一的音視頻技術拓展到和AI、5G、大數據結合越來越緊密的
另外消費類視頻監控在傳統視頻監控的基礎上也發展起來，這部分主要面向的是我們消費者是To C業務。傳統視頻監控面向的主要是政府，企業等To B業務。現在很多家庭都用攝像頭實現遠程看家，遠程開門，遠程陪伴老人等，這部分屬於新興業務，量不大但是發展很迅速。像海康的螢石，360的小蟻等都屬於這個範圍。當然消費類視頻監控的產品形態也不僅僅是攝像頭，也包含智能音箱、智能門鎖、電子貓眼、兒童手錶等。
前者傳統視頻監控一般都是在局域網和視頻專網裏面，後者消費類視頻監控一般都是要放到公網上進行。這幾年隨着各種技術的交叉發展，傳統視頻監控改造成互聯網的需求越來越多，我總結了下面幾個原因：
1. 移動互聯網的發展徹底改變了用戶的使用習慣，現在人人都是一部手機，能在手機上辦的事絕對不會在電腦上操作，更不會一天24小時待到監控室目不轉睛的看着屏幕上的視頻監控畫面，那樣效率太低，所以爲了讓大家能隨時查看視頻和發生報警通知，第一步要做的事情就是要把視頻監控設備和互聯網打通，讓大家在APP，微信小程序隨時關注相關信息；
2. 隨着AI、5G技術的快速應用，視頻監控要跟各行各業結合起來，不聯網這些技術想落地很困難，想這種智慧城市類項目，第一步要做的事情就是消除信息孤島，所以還是要把攝像頭的能力開發到外網，只要開發到外網纔有可能實現互聯互通和萬物互聯，進一步提升社會運轉效率；
3. 視頻監控行業本身的需要，現在雲技術大數據技術在視頻監控行業應用越來越多，這些技術可以大大降低視頻監控部署的難度，能把用戶資源高效利用起來，降低成本，但是這些安防廠商的雲基礎設施又很弱，所以自己想降低成本就需要提供自己設備的通外網能力，使自己能在公有云上實現軟件的自由部署和數據的自由流動，提升運營能力，減少重複勞動；
說了這麼多就是想講一個重點，視頻監控不是以前的那個安防概念了，是改造各行各業的一把利器，設備上雲互聯網化是使自己成爲一個高效工具的第一步，所以這件事不僅重要而且是大趨勢，消費類就更不用說，是需要你產品一出生就需要自帶的功能。
視頻監控互聯網化改造的實踐：
1.談怎麼做之前，先說下目前這塊現狀？
很不幸，這塊整個行業做的非常差，因爲這個行業一直都是有自己特殊羣體和場景的，最早以前還是模擬攝像頭，後來完成數字化改造，還沒冷下來，高清化、智能化這些新興技術就來了，所以這個行業沒有預期自己竟然能發展這麼快包括龍頭老大海康，更沒想到視頻監控和5G 、AI、雲計算、大數據這些技術都能緊密結合起來。所以視頻監控廠商在帶領這個行業時，沒有考慮到這些互聯互通問題，所以選用的技術棧跟目前萬物互聯需要的技術都有不少差異，但是一個行業一旦成型，想把新技術新標準快速貫徹下去，就有阻力了。
A. 目前攝像頭最重要的視頻傳輸採用的RTSP+RTP+RTCP技術，但是這些技術都跟互聯網特別是移動互聯網的需求有偏差，因爲類似APP、瀏覽器觀看視頻很少直接用這些協議和標準進行拉流和推流；
B. 視頻觀看這塊採用的是基於一些插件化技術和自研的播放器，這跟目前的HTML5無插件播放嚴重不匹配的，不僅兼容難而且耗費人力、精力，特別對於Flash插件明年各大瀏覽器將徹底不支持了。
C. 視頻編解碼雖然採用了H.264、H.265編碼，但是裏面往往有自己的私有碼流，其次音頻編碼格式很多還是G7xx系列，都面臨標準化適配和轉碼的問題。
D. 設備管理和會話這塊，要麼是私有協議要麼是基於SIP的GB28181協議或者ONVIF協議，這些協議本身複雜也不是爲視頻監控類業務專門開發的，所以問題非常多。
E. 安全這塊非常弱，通外網的協議基本不支持，這些都是讓人頭痛的地方。
2. 那麼到底怎麼實踐？
首先哪裏有需求，哪裏就有發展，視頻監控互聯網化長期看是個趨勢和必然需求，未來應該會在一些行業標準制定上或者攝像頭自帶功能能會有所突破，但是基於當下還是要實際問題實際解決，我基本總結了下面幾種思路：
消費類視頻監控
這類攝像頭目前基本都是私有協議，所以你買回去攝像頭一般再裝一個他們家的APP就可以觀看了，因爲這類視頻監控就你自己用，設備提供商可以提供端到端的技術實踐。一般他們都有云服務，這類攝像頭裏邊都是私有協議也不涉及開放和對接，所以這種情況技術比較容易實現，不是我們講解重點，涉及核心技術基本下面三點：
a. P2P相關技術，同一個wifi和局域網進行打洞，實現APP和攝像頭的直接互聯；
b. 私有協議傳輸技術；
c. 雲服務實現P2P打洞失敗情況下流媒體的轉分發和操作控制；
傳統視頻監控
這類設備比較複雜、功能比較多，設備廠商比較多，所以設備要上雲，具體看你需要的功能有哪些，如果僅僅是觀看視頻類需求也就是跟碼流直接相關需求，相對來說比較容易實現，但是你想充分使用設備所有的能力，那就比較複雜可選擇性不多，首先我們看一個傳統的視頻監控設備如果要在外網對接成功，一般能對接設備那些能力：
A.設備的發現、註冊、組織關係;
B.設備屬性的獲取，比如設備的廠商、型號、支持的編解碼類型、分辨率、傳輸協議、設備的狀態等信息；
C.設備屬性的設置和遠程控制，比如設備遠程重啓、定位、巡航，旋轉等操作
D.設備的流媒體能力，這塊包括直播，回放，下載、媒體的花式播放包括快進快退，倍速播放等；
E.設備事件的訂閱和通知，這塊包括一些人臉識別，視頻遮擋，設備異常檢測等基礎事件的訂閱和通知。
下圖是我在Web上的一個調試demo，大家可以瞭解下一個攝像頭的基本功能：
所以設備上雲還是跟自己的業務有關係，到底是隻接前端設備的音視頻能力還是整個能力全部對接，需要你結合自己的業務需求。但是無論那種業務，前端設備上雲基本下面三種方式：
[攝像頭有固定外網地址但只對接媒體能力]
1. 如果前端設備有固定外網IP，當然這種情況比較少，因爲外網IP現在是稀缺性資源，國內對IPV6落地速度明顯慢於歐美國家，所以只適合特殊場景領域，隨着IPV6發展，要是每個設備都有一個外網地址，那這件事變得就容易起來了。如果設備支持外網IP：僅僅對接設備的音視頻能力，則用設備原生支持的拉流協議進行拉流和控制即可，一般設備都支持rtsp主動拉流同時支持rtp傳輸碼流，這種你的基本開發工作量就是開發一個rtsp客戶端，這部分能用的開源軟件Live555或者FFmpeg，前者好處是兼容性做的非常棒，能適配各種前端情況對rtsp協議的實現情況即使不支持自己修改代碼也容易，FFmpeg方案就是實現簡單，但是兼容性不太好操作，畢竟Livee555已經開源一二十年了，而且只針對RTSP協議棧，實現比較優秀，當然你還可以選擇自己開發。
[攝像頭有固定外網地址對接設備所有能力]
2. 如果要對接整個設備能力，你可以選擇前端設備支持的國標GB28181協議或者國際協議ONVIF，這兩種設備接入協議行業設備一般都支持，你做好這兩套協議的客戶端直接對接設備即可。
[攝像頭在局域網但只對接設備媒體能力]
3. 如果設備在局域網部署只有內網IP，這種情況還是分兩種方法對接：
A. 只對接設備音視頻能力同時設備支持推流協議如RTMP，現在攝像頭有些可以支持RTMP原生推流，那就很簡單你在外網部署一個RTMP收流服務器即可，然後收到RTMP碼可以轉協議和轉封裝通過其它如HLS-TS、HTTP-FLV分發出去，你可以參考這篇文章《在HTML5上開發音視頻應用的五種思路》。
B. 只對接設備音視頻能力但是設備本身不支持推流協議，需要你自己開發一個媒體流協議轉換網關部署到設備側，用RTSP向設備拉流然後轉成RTMP推流到部署在公網的CDN或者RTMP收流服務器即可，當然只要把RTSP流拉上來，怎麼分發都行，轉成FLV用HTTP或者RTMP分發出去都可以。目前這塊SRS開源服務器就支持，缺點就是在攝像頭的用戶側都需要部署這個碼流協議轉換分發服務器。
[攝像頭在局域網需要對接設備所有能力]
4. 不僅要對接設備流媒體能力還有其它能力則可以用GB28181接入網關，這個網關即支持你部署到設備側內網也支持你部署到公網，讓設備主動註冊到公網。因爲GB28181協議的機制支持設備主動註冊，本質就是SIP+RTP，我們把公網上的服務器信息和相關配置到設備界面，然後設備主動註冊上來時就已經實現網絡穿透了，這樣我們下發信令就能到局域網的具體設備了，這樣既解決了設備發現和註冊，也支持了從外網操作設備，碼流則讓設備主動推流上來即可。
5. 如果海外項目不支持GB28181協議，但是設備支持國際協議ONVIF，則開發一個ONVIF接入網關，部署在設備側，但是部署ONVIF的機器支持雙網卡一個內網網卡用來和設備交互，一個外網網卡用來接收我們外網的一些操作請求。
對於上面說的這幾種我花了兩張圖簡單說明下：
將媒體協議轉換網關、GB接入網關、ONVIF接入網關部署在用戶側的示意圖：
GB接入網關部署在公網側的示意圖：
3. GB28181協議和ONVIF協議到底是什麼？
對監控沒有了解的人看到這兩種協議很懵逼，以爲是很高端的東西，其實並沒有，下面我總結了幾張PPT讓大家熟悉下這兩種協議，這是對接視頻監控設備的核心：
協議標準：
協議優缺點：
協議本質和技術棧：
再看下攝像頭在Web和移動端對接展示的效果，先用友商的展示吧：
Web端黃山景區直播：
家庭消費類 APP 端展示 ：
未來期望和想法：
視頻監控業務互聯網化改造的需求和項目會越來越多，但是要填的坑還很多，本質上還是視頻監控這方面業務落後於移動互聯網和AIoT的需求，沒有想到相關的AI、5G、大數據雲計算技術能對這塊產生這麼大的推動力，下面是我對這塊的一些期望和看法：
1. 國標和ONVIF還是主要的對接和上雲方式，這些協議會不斷髮布新版本和Feature適應當前需求，跟海康前同事聊了下，正在給公安一所體新需求和新標準；
2. 設備本身應該也會做出一些改變，無論從傳輸、信令控制、封裝編解碼都應該會考慮一些互聯網傳輸和觀看的相關需求，設備會原生支持一部分這種需求；
3. 國標基於SIP協議和RTP協議，但是SIP協議目前主要應用在分佈式的P2P音視頻會議和VOIP領域 ，但是目前視頻監控業務應用在政府、公安、文教衛領域具有明顯的方向性，一般從下級到上級，是明顯的多人對一個設備的控制，設備和客戶端不是對等的地位也是不一樣的，所以用SIP協議來控制會話和利用拓展來操作設備比較複雜，其次目前國標協議對會話控制和碼流傳輸缺乏明顯的安全支撐，很多攝像頭裸奔在互聯網上很不安全，這兩點估計是後面國標協議更新的主要方向。
4. 國標GB28181的編解碼類型只支持H.264，但是不支持H.265，對視頻的壓縮和存儲比較浪費，急需在編解碼增加該功能。雖然ONVIF支持H.265但是各個版本的協議不兼容給對接帶來很大困難，這兩塊也是吐槽比較多的地方，但是目前還看不到改進的希望，只能忍受這種缺陷和利用替代方案。
往期文章回顧:
音視頻解封裝：MP4核心Box詳解及H264&AAC打包方案
今天就說這麼多，祝您工作順利！
如果有疑問，你可以在公衆號後臺發消息諮詢我。
個人轉載內容至朋友圈和羣聊天，無需特別申請版權許可。
引用轉載該訂閱號文章，註明文章來源即可。
記得右下角點“在看”，還可以關注該訂閱號，防止遺漏推送哦
