流媒體調研:雲端視頻監控與可視化對講

背景

最近在調研調研流媒體、RTSP、SIP之類的,兩方面的目的:一是找一個雲端查看局域網監控的方案,一個是實現與門禁聯動的SIP 可視化對講。

雲端視頻監控

雲端視頻監控有三種方案:

  • 1、開發SIP服務器,實現GB28181協議,海大宇的IPC攝像頭也基本支持,但是如果有存儲30天的這種需求,對於雲端來說,雲盤就太昂貴了。

  • 2、上下級聯動,通過海大宇的SDK調用攝像頭NVR(IPC攝像頭一般自帶)或硬盤錄像機,再推送雲端。

  • 3、上下級聯動,通過RTSP(攝像頭一般都支持此協議)拉流錄像,在雲端下發命令時推送實時的或曾經的錄像視頻至雲端。

雲端視頻監控之前選定的方案是採購h5stream,可以上下級聯動,使用簡單,海大宇等主流攝像頭都可以支持。

但是因爲需要每臺機器都部署一個license,比較煩人;操作步驟是先部署,再郵件申請license,再激活,要弄兩次,沒法直接接入,在物聯網實施的時候特別尷尬。費用倒是不貴,一個license百元左右。

然後開始重新調研。

2020年年初,我在疫情放假期間曾經基於網上的教程做過一個使用nginx-RTMP + OBS實現的推流直播,瀏覽器上調用.m3u8的分片流,但是分片流這種方式延遲太高了。

調研SIP時發現有一個國人開發的C++流媒體庫不錯,ZLMediaKit;地址是https://github.com/xia-chu/ZLMediaKit。並且有許多優秀的作者基於ZLMediaKit開發了對應的SIP服務,且實現了公安制定的國標GB28181-2011、GB28181-2016協議。

在豬豬羣裏問了一下有沒有java實現的流媒體庫,有同學說red,去搜了下,發現red5的github還在更新維護,倒不失爲一個選擇。但是最新的red5版本是基於jdk11的,就有點犯怵了。

另有羣裏的同學貼出了知乎上的答案,雖然已經是2015年的了,但還是具有參考價值,可以看一看:

  • Live555 (C++) 流媒體平臺框架

  • EasyDarwin (C++,國產精品)實時流媒體播放服務器程序

  • DarwinStreamingSrvr (C++)

  • Flash流媒體服務器

  • Red5 (Java)流媒體服務器

  • Open Streaming Server (Java)FMS流媒體服務器 (Adobe,收費的)

  • Wowza流媒體服務器(Java)開源流媒體平臺

  • FreeCast(Java)

帖子地址:https://www.zhihu.com/question/31160392。

Live555 EasyDarwin都是不錯的方案,EasyDarwin 還是我們合肥的,是一家叫青犀的公司。

上面沒列入而我調研的還有 liveGBS 、h5stream,這幾種方案都是可以上下級聯動的,但是因爲價格的原因,主要是青犀千路以下比較貴,我們目前還沒那個量級,所以選擇了可以分批次購買的h5stream。

SIP音視頻對講

說完視頻監控,說說SIP 音視頻對講。

如果只是做SIP 音視頻對講的話,找到了一個不錯的解決方案,即是flashphoner,地址https://flashphoner.com/。Android、ios、web都支持。

然後在查看flashphoner的過程中,找到了這個帖子【25個常用免費SIP軟電話】,地址:https://zhuanlan.zhihu.com/p/313345953。

列表如下:

XLite (Now Bria Solo)
linphone
MicroSIP
3CX Softphone
ZoIPer
Blink
Grandstream WAVE
(Qutecom)Wengo
Damaka
AdoreSoftphone
MiniPAX
MizuPhone
FlashPhone
FaramPhone
Mirial Softphone
WXCommunicator
Twinkle
IAXComm
SJLabs SJPhone
Phoner
DIAX
ExpressTalk
T-Max Dialer
IPComms
IMSDroid

當然,並沒有一一驗證。

如果選好了後端的流媒體方案,前端的播放怎麼弄?想到了使用webRTC。

在搜尋webRTC的時候,找到了極客時間李超的課,在其音視頻直播課中,也推薦了幾款開源的流媒體軟件:

  • licode、

  • Janus-gateway

  • Mediasoup

  • Medooze

Meooze、Mediasoup、Licode這三個流媒體服務器的媒體通信部分都是由 C++ 實現的,控制邏輯通過 Node.js 實現。Janus-gateway是完全通過 C 語言實現的。據說是都可以支持500人的多人視頻。

商業上還有個大牛直播,據自己介紹延遲極低,適合做直播服務。

調研後的想法

就這些吧,這是目前調研的一些成果。有些也並沒有做深入的研究。有些部署起來較爲麻煩,花了半天沒部署好,就放棄了。

目前的想法是將視頻全部推到雲端肯定不現實,帶寬太貴了。所以準備在局域網中部署客戶端,拉流RTSP,使用webRTC或其他js工具播放,然後使用frp這類穿透軟件,可以直接暴露服務給外網訪問。

甚至可以將js中的播放地址替換爲局域網中播放地址,使用iframe的方式嵌套,只要解決跨域問題,就可以直接讓視頻在客戶局域網的本機上播放。

當然,如果不是對應局域網內的客戶機訪問就很尷尬了,所以還要做好雲端訪問與本地訪問的隔離。

回過頭來想想,我們在A、B兩個局域網,使用A區的電腦訪問系統,然後展示B區的攝像頭,也不是不可以,使用NAT轉換的方式,進行點對點訪問就行了,只是把雲端作爲一個隧道,那流量是不是可以破開帶寬的限制呢?

目前的想法可能有別於主流的解決方案,也不知道能不能實現。做做看,否則帶寬真的是個大問題。

至於可視化對講,如果自研的話,目前傾向於採用 ZLMediaKit,在其上實現SIP 信令。

但是可視化對講方案是比較成熟、通用的,也沒有個性化的需求,所以找幾家商業公司比較下,應該就可以確定了。

附錄:名詞簡析

RTSP:實時流協議(Real Time Streaming Protocol)。流媒體公有協議,專門用以控制流媒體服務器。如播放,錄製和暫停。基於UDP協議,傳輸ts(.m3u8)、MP4格式流。目前多用於安防領域。

RTMP:實時消息協議(Real-Time Messaging Protocol)。目前是Adobe的私有協議,未完全公開,跟RTSP擁有一樣的功能。基於TCP協議,傳輸flv、f4v格式流,目前是比較主流的流媒體協議。有很多變種,具體看維基。

RTSP一般需要2-3個通道,數據和命令通道分開,RTMP和HTTP在一個通道上傳輸命令和數據。

SIP:會話發起協議(Session Initiation Protocol),由IETF(Internet Engineering Task Force,因特網工程任務組)制定的多媒體通信協議,也被稱作信令協議,所以SIP服務也稱作信令服務。

SIP可以用於創建、修改和終止包括視頻、語音、即時通信、在線遊戲和虛擬現實等多種多媒體元素在內的交互式用戶會話。


本文分享自微信公衆號 - 架構師之殤(ysistrue)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章