流媒體調研：雲端視訊監控與視覺化對講

姚毛毛發表於2021-02-04
視覺化

背景

最近在調研調研流媒體、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可以用於建立、修改和終止包括視訊、語音、即時通訊、線上遊戲和虛擬現實等多種多媒體元素在內的互動式使用者會話。

相關文章