更好用的Web端H265播放技術架構

語言: CN / TW / HK

 

作者簡介: 百度CyberPlayer、雲端非線性編輯、音影片工程師 

h265web.js作者  (https://github.com/numberwolf/h265web.js)

 

01背景

隨著影片內容的佔比逐步擴大,直播、點播內容越來越多;在此基礎上,影片傳輸的頻寬成本也跟著上漲,降低成本為第一要務,首先要考慮的就是增加影片的壓縮率。而目前網路上多為H.264的影片,若將網路上的影片壓縮為H.265,可以較H.264壓縮率更高、節省更多成本。

瀏覽器對編碼的支援

當前瀏覽器下我們常用的方式是Video標籤和MSE的方式來進行影片播放,但是現階段的瀏覽器基本都只支援H.264的解碼和播放(瀏覽器內部完成了解碼)。

對於原生對於265幾乎無支援能力,僅僅只有Apple的Safari瀏覽器的部分版本支援H.265解碼播放,但是根本無法滿足生產環境下的需求。

圖1. 瀏覽器對於H.265播放的能力支援度

 

瀏覽器對於MSE的支援

下圖,為瀏覽器對於MSE的支援程度,可見MSE支援也不是很普遍。

圖2. 瀏覽器對於MSE的能力支援度

02網頁H265播放架構

 

目前需要解決兩個問題:

  • 網頁端的一個通用H.265影片播放問題。

  • 網頁端對於MSE不支援的問題解決方案。

一個播放器的組成部分

圖3. 播放器的組成部分

  • 影片部分

對於H.265播放問題,我才用了WebAssembly的解決方案,通過C/C++開發的解碼和解封裝模組打包為wasm檔案。

如下圖,大部分瀏覽器都已經支援了wasm。

圖4. 瀏覽器對wasm的支援度

 

  • 音訊部分

音訊部分,採用了WebAudio方式去進行音訊解碼和播放。

如下圖,大部分瀏覽器都已經支援了webaudio。

圖5. 瀏覽器對Webaudio的支援度

H265播放詳細設計

  • 整體設計

圖6. H265播放整體設計圖

主要分為:

  1. Js-Demuxer/Wasm-Demuxer

         解封裝器,分為JS部分和WASM(C/CPP)部分實現,應對不同的BOX。

     2.  Wasm-Decoder

          解碼器,主要針對265幀的解碼。

     3. WebAudio-Player

         音訊播放器,承擔了AAC音訊的播放,包括Seek、Play、Pause等行為。

 

  • 具體流程

     * 根據影片流`URL尾綴`和`協議`進行初始化BOX判斷

     * Fetch獲取到影片流媒體開始下載

     * 下載Chunk輸入`Demuxer`進行Probe

     * 探測到具體的`Mediainfo`後,開始進行幀資料讀取

     * 讀取到音影片幀後餵給`Queue`* 影片幀餵給`wasm-decoder`進行解碼,快取一定的幀資料

     * 影片幀交給OpenGL(WebGL)進行渲染

     * 音訊幀獲取Body資料,根據samplerate和channel等資料組合ADTS頭。(如下圖)

圖7. 音訊幀獲取Body資料

     * 音訊組包,ADTS頭+Body 組音訊包餵給Webaudio進行解碼播放。

 

  • 難點

     * WebAudio不支援push佇列播放的方式,我才用了交叉上下文的形式解決了此播放問題。

     * 影片下載過程中可能會阻塞瀏覽器其它行為,搶用資源,這部分需要才用worker非同步下載的方式。

    * 影片Seek如何最快精準Seek操作,這部分我採用了類搜尋引擎的方式,構建了多層幀索引進行檢索後精準Seek。

 

效果

  • 整體播放Demo

圖8. 播放器整體Demo

  • 效能

     * 目前保守測試可以併發兩路1m/s的720P HEVC影片播放。

     * 支援1路1080P影片播放。

 

  • 能力

    * 支援點播、直播

     * 支援安防、點播、直播場景

03心路歷程

起點

最初要寫web 265播放器的念頭始於去騰訊之前一段時間,之前也做過Native端的播放器;為了深耕音影片,當時回顧總結了一下自己的技術深度和廣度,想從Web端265播放器入手把web上的音影片技術棧的廣度和深度進行補充。

之前也只是寫了一個Demo級別的掛在Github,後來來了百度,才開始正式在個人業餘時間開始維護起來,逐步引入生產環境,對外輸出。

 

研發那些事

其實整個研發歷程中,讓我懂得了,無論做任何事情,要`勇於重構`(建立在你對整體技術架構非常自信能hold住才可以).

沒有一勞永逸,一成不變的產品設計和技術架構,你總要隨著使用者、時代的變化而變化;當然你也可以不去重構,而是堆砌,最終導致的結果就是:一個月不去維護的話,你可能"看著鏡子裡的自己都感覺陌生"。

 

  • 困難

* 整體專案都是一個人維護與研發,你的出發點建立在技術實驗上,但是後續用的人越來越多,開始考慮生產環境,你不得不重構,這注定是一個耗時且使用者無感知的 痛苦過程。

* 越來越多的Feature需求,你要做非常多的取捨,因為`週末只有2天`,對於產品的設計、技術需求的取捨必須做精確的判斷;對標競品、確定你的使用者群體是安防、短影片、長影片 或者是研發類用途,這部分的成本投入也佔了不少的比例。

* 社群使用者不看README、喜歡私聊(不在群裡提問)也會帶來很多困擾,會花費非常打的成本投入去打磨使用者。

* 做開源就要有做開源的覺悟,哪怕只有付出。

 

  • 收穫

其實搞得開源專案不止這一個,只不過今天的主體是265播放器。

    * 對於Web端265的播放器使用群體有了一個清晰的認知和劃分,這部分對於日後的產品設計和迭代有非常大的幫助。

    * 對於我個人而言,對於播放的音影片技術場景和Web端的音影片技術棧有了從前到後的完整認知 和 技術儲備(從0-1全部是我一個人完成的)。

    * 結識了許多業內大佬朋友、還有前輩,生活也更加充實了。

    * 這幾年開源產品、技術架構做了非常多,產品設計、互動設計、產品運營思維也是不知不覺的就培養了起來。

04結語

播放器並非一個一勞永逸的事情,隨著時代的進步、場景的遞增,播放器也需要緊跟步伐。

百度Cyberplayer正在支援HDR10的播放開發(歡迎使用)。

點選進入獲得更多技術資訊~~