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

在Chrome、Edge、Firefox等當前主流的瀏覽器中，即使是HTML5標準的Video也並未對RTSP流播放提供原生支援，從而導致如何在當前主流的瀏覽器中實現低延遲、低成本播放多路RTSP成為了一個重大技術難題。這幾年國內外的技術專家經過不斷研究總結，形成一些閉源或開源、收費或免費的方案，但多數時候無法完全滿足客戶的實際需求，要麼相容性和穩定性不好，要麼播放延遲高，首屏畫面顯示慢；尤其是播放高解析度的RTSP流時，卡頓、花屏現象難以根除。而且攝像頭比較多時還需要專用伺服器高負荷的運轉來支援轉碼轉流，頻寬的高頻佔用對系統其它業務的影響不可忽視，系統綜合執行成本高，體驗差。

二、現有方案

在瀏覽器中實現播放RTSP實時視訊流，大體上有如下幾個方案：

1.瀏覽器外掛方案

此方案主要適用於在IE及Chrome 45以下版本的瀏覽器，在2015年前是絕對主流的選擇。使用ActiveX播放控制元件或NPAPI播放外掛實際呼叫的是本地原生程式進行直接播放，從而可充分利用本機硬體解碼和硬體加速渲染播放，可實現低延遲、低成本多路穩定播放的良好效果。一般使用VLC這個最流行的開源跨平臺多媒體播放器，IE及Chrome、Firefox低版本瀏覽器分別有對應的播放外掛實現，VLC對移動端支援也非常好。此方案非常靈活，可以方便的對接各品牌的視訊流，也可以很容易實現截圖和錄影功能。缺點是需要額外安裝VLC客戶端軟體，對個別明確要求不能用外掛的場景不適用。攝像頭廠家一般也會提供適配的播放外掛，比如海康威視提供的播放控制元件Web版，是和自己的DSS系統捆綁使用的，但不支援在Firefox高版本中執行。

1.先轉碼再轉流方案

此方案需要架設一個或多個視訊流轉碼伺服器，先在伺服器上對RTSP流用ffmpeg進行轉碼串流成RTMP，然後前端使用VideoJS再呼叫Adobe Flash Player進行播放，然而2021年開始基於Chromium核心的所有瀏覽器徹底取消了對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等，商業用途都是收費的。

2.先轉流再轉碼方案

此方案的典型代表是Streamedian公司的免外掛播放器Html5 RTSP Player，專案地址https://github.com/Streamedian/html5_rtsp_player。此方案需要架設一個Web Socket的視訊流轉發伺服器，前端連線到此伺服器後，服務端不斷把RTSP視訊流通過Web Socket不斷轉發給前端的JS處理庫，JS處理庫再把視訊流轉換為Video所支援的MP4後播放。

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

2.擴充套件程式方案

此方案典型代表是基於Chrome瀏覽器的PPAPI外掛技術實現的開源播放器VXG RTSP Player，專案地址是https://github.com/VideoExpertsGroup/Chrome.RTSP.Player。此方案很顯然不適用於IE和Firefox等瀏覽器，也不適用於低於45版的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控制元件經常彈出警告，使用者體驗很差，維護升級也很麻煩。

2.Wasm方案

此方案採用的是Chrome等高版本瀏覽器所支援的一種方便把更復雜的原生應用直接搬進 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打包的控制命令實現控制播放視窗。

目前市場上已經有采用此思路實現的相關軟體和實施案例，比如猿大師中介軟體，提供了一個統一的不依賴瀏覽器本身擴充套件技術的外接系統，能實現當前主流瀏覽器的全相容，包括低版本的Chrome和IE瀏覽器；而且小程式的下載和安裝提供了類似ActiveX控制元件的機制，去掉了一些影響使用者體驗的告警並附加了呼叫方安全驗證機制。而這個播放視窗程式也提供了比較好的範例實現，難能可貴的是在這個播放視窗還直接實現了多路RTSP的同時播放支援，可點選切換播放視窗焦點和全屏播放。據瞭解，此方案已經成功在機場、地鐵站、交管局等客戶現場完成實施並取得了良好的效果，獲得了客戶的一致好評，畢竟能實現低延遲、低成本的多路同時播放是硬道理。

某視訊監控大廠最近也釋出了類似的版本，不過經過測試發現，不支援Firefox高版本瀏覽器不說，其播放視窗程式框架採用臃腫的QT來實現的，看上去播放視窗只是模擬顯示的效果而不是真正內嵌到瀏覽器中的，導致和瀏覽器的聯動效果比較差，程式包也很大，且未提供前端自動升級和安全呼叫機制。另外想用此播放元件還必須購買其DSS系統，而這套DSS系統的售價不菲，對客戶來說價效比很低。

對於個別客戶提出的免外掛播放要求，主要是擔心安全問題。其實所謂的免外掛實現方案中，也是需要瀏覽器從伺服器端下載JS版播放器的，而外接版只不過下載的是本地版播放器，只需要保證下載到本地的播放器程式是安全的即可，必要的話可通過開放播放器原始碼來打消客戶對安全的顧慮。還有原因就是需要額外下載外接程式導致部署和升級麻煩，但為了超低延遲的穩定播放效果，這個就是必要的代價了，況且前文提到的猿大師中介軟體提供了播放小程式的自動安裝和升級機制，這樣就大大降低了部署和升級的壓力，效果比IE中的ActiveX控制元件還好。

四、總結
一個好的技術實施方案，首先是要滿足客戶的剛性需求，其次是儘量降低採購、開發、實施及維護的總成本，再次是是良好的相容性和穩定性，最後需儘量確保技術方案不能因為瀏覽器的升級而失效。本文基於當前最新的技術資訊和實踐經驗，提供了這樣一個穩定可靠、相容性好、低延遲又可同時穩定播放多路RTSP的低成本半開源技術方案，尤其適合播放高解析度的RTSP，以供大家選型參考。

猿大師中介軟體官網：http://www.yuanmaster.com