更好用的Web端H265播放技術架構
作者簡介: 百度CyberPlayer、雲端非線性編輯、音影片工程師
h265web.js作者 (http://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播放整體設計圖
主要分為:
-
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的播放開發(歡迎使用)。
- 智慧大資料,看這本白皮書就夠了
- 效果提升28個點!基於領域預訓練和對比學習SimCSE的語義檢索
- 百度基於 Prometheus 的大規模線上業務監控實踐
- AI CFD:面向空天動力的科學機器學習新方法與新正規化
- 飛槳圖神經網路PGL助力國民級音樂App,創新迭代千億級推薦系統
- 全新快取元件,大幅加速雲上飛槳分散式訓練作業
- 知乎使用者畫像和實時資料的架構與實踐
- 全新快取元件,大幅加速雲上飛槳分散式訓練作業
- “千言”開源資料集專案全面升級:資料驅動AI技術進步
- 百度CTO王海峰:AI大生產平臺再升級 助力中國科技自立自強
- 百度智慧雲可程式設計閘道器技術升級,為AI原生雲打造10T級高速智慧雲網絡
- 百度APP影片播放中的解碼優化
- 百度智慧雲可程式設計閘道器技術升級,為AI原生雲打造10T級高速智慧雲網絡
- 飛槳攜手百度超級鏈推出首款可信分散式AI開源產品——“鏈槳”
- 百度API介面智慧化測試探索與實踐
- 乾貨分享!邊雲融合的時序時空資料庫實踐詳解
- 乾貨分享!邊雲融合的時序時空資料庫實踐詳解
- 資料有了,如何構建資料資產?
- 飛槳攜手百度超級鏈推出首款可信分散式AI開源產品——“鏈槳”
- 資料有了,如何構建資料資產?