早期很多攝像頭視頻流使用的是RTSP、RTMP協(xié)議，播放這類協(xié)議的視頻通常是在網(wǎng)頁上安裝插件。但現(xiàn)在越來越多的用戶，對于網(wǎng)頁安裝插件比較反感，且隨著移動設備的普及，用戶更多的希望使用手機、平板等移動設備，直接可以查看這些協(xié)議的視頻。那是否有什么方案可以直接網(wǎng)頁打開RTSP、RTMP協(xié)議的視頻，直接觀看不用安裝插件呢？而且對于攝像頭的數(shù)據(jù)，盡可能低延遲的獲取實時畫面。

其實很多攝像頭廠家也注意到這個問題，最新的攝像頭廠家，也有很多已經(jīng)支持了無插件播放，比如通過WebSocket等新的傳輸協(xié)議，取代rtsp等協(xié)議，通過網(wǎng)頁直接播放。但這個方案對于新攝像頭沒問題，但對于使用RTSP/RTMP/FLV等格式或協(xié)議的視頻并不適用，因此這種情況不做過多討論。

另一種方案是基于JS、WASM等前端技術，在前端直接拉流、解碼、顯示，比如flv.js等前端播放技術，有不少開源的方式，可以實現(xiàn)一些特殊格式、特殊協(xié)議的直接前端解碼處理。但該類方式一般會有占用較多終端計算資源。而且對于iOS等很多設備的瀏覽器兼容性不友好，該方案的通用性弱一些。

基于前端不合適，那換個思路基于后臺轉(zhuǎn)換能不能行呢？比如將rtsp轉(zhuǎn)為m3u8這何總HLS協(xié)議，做成適合H5頁面直接播放的視頻格式。但如果轉(zhuǎn)為HLS(m3u8)這種，有個問題：延遲會比較高，因為m3u8的分段，導致需要一些緩沖的片段，因此會增加很多延遲。

那還有沒有其他的方案呢？點量云流基于多年視頻流式傳輸經(jīng)驗，認為后臺拉流轉(zhuǎn)換時將這些攝像頭，或rtmp等各種協(xié)議的數(shù)據(jù)，直接轉(zhuǎn)為WebRTC的方式，可以很好的解決這個問題。這種將RTSP/RTMP/FLV等直播協(xié)議、攝像頭數(shù)據(jù)，轉(zhuǎn)為WebRTC方式，有以下優(yōu)勢：

1、良好的兼容性：目前主流的瀏覽器均支持WebRTC，因此該方案無需擔心瀏覽器兼容性問題，用戶可以選擇自己習慣的瀏覽器使用。

2、對設備性能占用小：基于瀏覽器的良好支持，可以借助硬解碼能力，從而對設備性能占用比較低。

3、低延時、實時性優(yōu)：WebRTC是一種為實時流媒體設計的協(xié)議，通過這種，延遲可以低至100ms以內(nèi)，完全可以滿足攝像頭領域的低延遲需求。

4、前端引入方便、代碼量小：前端不再需要復雜的播放器解碼等方式，只需要用標準的WebRTC就可以接入。雖然也有一部分技術通過WebSocket方式獲取視頻，但往往這種拿到視頻數(shù)據(jù)后，還需要基于類似FLV.js等技術，對視頻數(shù)據(jù)要進行復雜的處理，才能進行顯示，便捷性不如WebRTC。

以上解決方案工作量主要在后端，拉取RTSP、RTMP等數(shù)據(jù)，中轉(zhuǎn)為WebRTC協(xié)議，不過已有成熟技術可使用。點量團隊作為專業(yè)視頻流公司，有成熟技術可實現(xiàn)：傳入RTSP/RTMP等地址直接生成WebRTC使用，并提供完善的前端示例，后臺的部署安裝也比較便捷，有專門的技術服務，無需從頭研究。該方案不同于二次轉(zhuǎn)碼，只是修改視頻的封裝，無需二次轉(zhuǎn)碼，因此擔負起也可以支持大量攝像頭同時使用。具體架構(gòu)圖如下：

以上系統(tǒng)平臺具體功能有：

1、支持多協(xié)議、多設備接入：

支持RTMP/RTSP/Onvif/GB/T28181/等協(xié)議，多廠商品牌的設備接入

2、標準化輸出，多終端全平臺覆蓋：

輸出標準的WebRTC，支持幾乎全部主流終端瀏覽器打開播放

3、提供二次開發(fā)、定制等服務；