在Chrome、Firefox等高版本瀏覽器中 實現低延遲播放海康、大華RTSP

一、背景

現在到處是攝像頭的時代,隨着帶寬的不斷提速和智能手機的普及催生出火熱的網絡直播行業,新冠病毒的大流行又使網絡視頻會議系統成爲商務會議的必然選擇,因此RTSP實時視頻流播放及處理不再侷限於安防行業。在如道路、工廠、樓宇、學校、港口、農場、景區等場景實施的信息化系統中,已基本全採用B/S架構,迫切需要在瀏覽器中嵌入多路攝像頭RTSP流的超低延遲(小於500毫秒)播放功能,而在IE及Chrome 49以下版本等瀏覽器中,採用ActiveX控件或NPAPI插件即可實現。然而美好總是短暫的,從2015年開始Chrome及Firefox等瀏覽器紛紛取消了NPAPI插件的支持,而IE又在與Chrome及Firefox等瀏覽器競爭的過程中不斷被用戶拋棄,到現在市場份額已降到可憐的個位數。微軟在幾經折騰後,索性也擁抱Chromium內核推出Edge新版來殺死自己的IE,以挽救自己在瀏覽器這塊岌岌可危的江湖地位。

在Chrome、Edge、Firefox等當前主流的高版本瀏覽器中,即使是HTML5標準的Video也並未對RTSP流播放提供原生支持,從而導致如何在當前主流的瀏覽器中實現低延遲、低成本並可同時播放多路RTSP成爲了一個重大技術難題。這幾年國內外的技術專家經過不斷研究總結,形成一些閉源或開源、收費或免費的方案,但多數時候無法完全滿足客戶的實際需求。

二、現有方案

在瀏覽器中實現播放RTSP實時視頻流,大體上有如下幾個方案:

  1. 瀏覽器插件方案

此方案主要適用於在IE及Chrome 49以下版本的瀏覽器,在2015年前是絕對主流的選擇。使用ActiveX播放控件或NPAPI播放插件實際調用的是本地原生程序進行直接播放,從而可充分利用本機的硬件加速能力,可實現滿意的多路低成本、低延遲播放效果。一般使用VLC這個免費開源的跨平臺多媒體播放器,IE、Chrome、Firefox等瀏覽器分別有對應的播放插件,對移動端支持也非常好。此方案非常靈活,可以方便的對接各品牌的視頻流,也可以很容易實現截圖和錄像功能。缺點是需要額外安裝VLC軟件,對個別明確規定不能用插件的場景不太適用。攝像頭廠家一般也會提供適配的播放插件,比如海康威視提供的播放控件,是和自己的DSS系統捆綁使用的。

  1. 先轉碼再轉流方案

此方案需要架設一個或多個視頻流轉碼服務器,先在服務器上對RTSP流用ffmpeg進行轉碼串流成RTMP,然後前端使用VideoJS再調用Adobe Flash Player進行播放,然而2020年底開始基於Chromium內核的所有瀏覽器就徹底取消對Adobe Flash Player的支持,VideoJS失效。不過幸好還有開源的替代播放方案flv.js(https://github.com/bilibili/flv.js)工作原理是要求在服務端先把RTSP視頻流轉換爲flv後用Web Socket或WebRTC推送到前端,前端收到後再轉換爲Video所支持的MP4後播放,這就導致RTSP視頻流,需要經過2次轉碼才播放,畫面延遲時間大幅度增加,保守估計延遲至少也是2-3秒級別了。況且如果有多路視頻流時,服務器端轉碼和轉流對CPU、內存、網絡帶寬的壓力大幅度增加,長期使用成本很高。此方案要求瀏覽器支持流媒體擴展特性(MSE),且無法利用本機硬件加速實現解碼和渲染。優點是可兼容移動端網頁播放。

此方案在國內有TSINGSEE的免插件EasyPlayer RTSP播放器,項目地址是https://github.com/tsingsee/EasyPlayer和linkingvision的免插件播放器H5stream,項目地址是https://github.com/linkingvision/h5stream等。

  1. 先轉流再轉碼方案

此方案的典型代表是Streamedian公司的免插件播放器Html5 RTSP Player,項目地址https://github.com/Streamedian/html5_rtsp_player。此方案需要架設一個Web Socket的視頻流轉發服務器,前端連接到此服務器後,服務端不斷把RTSP視頻流通過Web Socket不斷轉發給前端的JS處理庫,JS處理庫再把視頻流轉換爲Video所支持的MP4後播放。

此方案不支持IE瀏覽器,最大的問題是畫面延遲達數秒,首屏內容顯示慢,而且無法利用本機硬件加速實現解碼和渲染,CPU佔用高,播放時有卡頓現象,體驗比較差。另外無法實現本地自動截圖、錄像等操作。此方案同樣要求瀏覽器支持流媒體擴展特性(MSE),對延遲不敏感的單源播放尚可,多路播放就只能洗洗睡了,另外根據一些用戶的反饋,對各品牌攝像頭的兼容性也不太友好,作爲商業用途使用是不可行的。

  1. 擴展程序方案

此方案典型代表是基於Chrome瀏覽器的Native Client(NaCl)和Portable Native Client(PNaCl)技術實現開源播放器VXG RTSP Player,項目地址是https://git.code.sf.net/p/rtsp-player-chrome/code rtsp-player-chrome-code。此方案很顯然不適用於IE和Firefox等瀏覽器,也不適用於49版以前的Chrome 瀏覽器。VXG RTSP Player是Chrome瀏覽器的擴展程序,對國內客戶來說,由於谷歌服務器在牆外,想要大規模自主可控部署是不現實的。另外最關鍵的是谷歌已官方宣佈,2021年6月終止對NaCl,PNaCl和PPAPI API的支持,因而此方案也無繼續探討的必要。

  1. 雙內核方案

此方案典型實現是採用Chrome瀏覽器上的擴展程序IETab來實現,官方網站是https://www.ietab.net,通過在Chrome標籤頁界面覆蓋加載顯示一個IE內核渲染的網頁,此網頁再調用比如VLC的開源ActiveX多媒體播放控件實現。此方案和方案4一樣,存在大規模自主可控部署難問題。另外和上面的瀏覽器插件方案類似,需要在播放終端電腦中下載運行IEHelpTab.exe客戶端程序,對一些高安全要求無插件播放的場景來說不適用。最大的問題是在Chrome網頁中對播放控件的控制很難實現,只有網頁和播放控件都是在IE內核環境下才可以,而IE對當前一些新技術和前端主流框架的兼容已經不行了,況且IE對運行和下載安裝ActiveX控件經常彈出警告,用戶體驗很差。

  1. Wasm方案

此方案採用的是高版本瀏覽器所支持的一種方便把更復雜的原生應用直接搬進 Web 的標準技術,然而對瀏覽器的兼容存在很大問題,IE肯定是不支持的,低版本的Chrome及Firefox等瀏覽器也不支持Wasm,具體兼容性可看這裏https://caniuse.com/wasm。實現的基本思路就是把RTSP視頻流通過ffmpeg的Wasm版軟解碼成Video所支持的MP4後播放,由於Wasm不支持硬件解碼,對多路同時播放來說,CPU和內存佔用會比較高,性能有很大瓶頸。此方案有時應用在需要支持H265編碼的場景,同樣要求瀏覽器支持流媒體擴展特性(MSE)。由於存在諸多兼容性問題,此方案實際應用的案例較少。

、改進方案

通過上述總結的現有技術方案可以看出,想要在瀏覽器中實現低延遲、低成本的多路RTSP同時播放,只有做到不轉碼直接播放和充分利用終端的硬件加速這兩個核心要求才能辦到,這就只能採用插件方案。核心就在於如何在瀏覽器中實現一個統一的不依賴瀏覽器本身擴展技術的插件系統,同時必須讓改進方案對各品牌及各版本瀏覽器有比較好的兼容能力才具有較大的實用價值。所以改進方案基本思路就是要在瀏覽器網頁中指定位置和大小,實現一個內嵌到網頁中顯示的播放窗口,這個內嵌播放窗口前端還必須可對其進行控制,而且播放窗口必須跟隨瀏覽器窗口的移動和縮放、網頁滾動、標籤頁切換、關閉等操作進行自動聯動。這就要求播放窗口必須是本地程序,最好用高性能的C++語言來實現,這樣還可充分利用終端的硬件加速能力。這個播放窗口同時提供Web Socket的服務端和JSON打包的命令解析執行模塊,前端就可以通過Web Socket連接後發送JSON打包的控制命令實現控制播放窗口。

目前市場上已經有采用此思路實現的相關軟件和實施案例,比如PluginOK中間件(https://github.com/wangzuohuai/WebRunLocal),提供了一個統一的不依賴瀏覽器本身擴展技術的插件系統,能實現當前主流瀏覽器的全兼容,包括低版本的Chrome和IE瀏覽器;而且對插件的下載和安裝提供了類似ActiveX控件的機制,去掉了一些影響用戶體驗的告警並附加了調用方安全驗證機制。而這個播放窗口程序也提供了比較好的範例實現,其具體調用方法可以參考這裏的說明:https://github.com/wangzuohuai/WebRunLocal/blob/master/Plugins/VlcWebPlayer/VlcPlayerApplet.txt,難能可貴的是在這個播放窗口還直接實現了多路RTSP的同時播放支持,可點選切換播放窗口焦點和全屏播放。據瞭解,此方案已經成功在多個客戶現場完成實施並取得了良好的效果,獲得了客戶的一致好評,畢竟能實現低延遲、低成本的同時播放是硬道理。下面是播放效果視頻地址:

http://zorrosoft.com/Files/VLCWebApplet_Play.mp4

某視頻監控大廠最近也發佈了此思路實現的版本,不過經過測試發現,不支持Firefox高版本瀏覽器不說,其播放窗口程序框架採用的是臃腫的QT來實現的,看上去播放窗口只是模擬顯示的效果而不是真正內嵌到瀏覽器窗口中的,導致和瀏覽器的聯動效果比較差,插件包也很大,爲提供前端自動升級和安全調用機制。另外想用此播放插件還必須購買其DSS系統,而這套DSS系統的售價不菲,對非安防行業客戶來說性價比很低。

對於個別客戶要求免插件的要求,主要還是因爲安全原因。其實那些所謂免插件的實現方案中,也是需要瀏覽器從服務器下載JS版播放器的,而插件版下載的是本地程序播放器,只需要保證下載到本地的播放器程序是安全的即可,必要的話可開放源代碼來打消客戶對安全的顧慮。另外原因就是需要額外下載插件程序導致部署和升級麻煩,爲了超低延遲的播放效果,這個是必要的代價,況且前文提到的PluginOK中間件提供了播放插件的自動安裝和升級機制,這樣就大大降低了部署和升級的壓力,效果比IE中的ActiveX控件更好。

、總結

一個好的技術實施方案,首先是要滿足客戶的需求,其次是儘量降低開發、實施及運營的總成本,再次是是良好的兼容性和可靠性,最後需儘量確保技術方案不能因爲瀏覽器的升級而失效。本文基於當前最新的技術信息和實踐經驗,提供了這樣一個穩定可靠、兼容性好、低延遲又可同時播放多路RTSP的低成本技術方案,以供大家參考。

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