本文轉(zhuǎn)自淘寶技術(shù)，文章詳細介紹了如何通過WebAssembly在移動Web端實現(xiàn)H.265解碼，既享受到了H.265更高的編碼效率，又實現(xiàn)了在多種移動端瀏覽器上兼容。未來，通過WebAssembly還可能實現(xiàn)對AV1等新一代Codec的支持。

隨著音視頻業(yè)務(wù)的快速發(fā)展，作為前端工程師，我們團隊也逐步深入到音視頻編解碼領(lǐng)域，涉及到流媒體技術(shù)中的文本、圖形、圖像、音頻和視頻多種理論知識的學(xué)習(xí)，并有機會大規(guī)模應(yīng)用到具體實踐中。

我們自研了Web播放器并支持h.265解碼，保持畫質(zhì)不變情況下，將碼流降低50%，達到減少帶寬成本，真正做到了h265解碼播放的全域覆蓋。本文主要分享了我們基于WebAssembly實現(xiàn)H.265格式的解封裝、解碼和播放。

背景

H.265 又稱HEVC(全稱High Efficiency Video Coding，高效率視頻編碼)，是ITU-T H.264/MPEG-4 AVC標準的繼任者。相比H.264，H.265擁有更高的壓縮率，也就意味著同樣碼率（又稱比特率是指每秒傳送的比特(bit)數(shù)。單位為bps(Bit Per Second)，比特率越高，每秒傳送數(shù)據(jù)就越多，畫質(zhì)就越清晰），H.265的畫質(zhì)會更清晰，更高的壓縮率就能使用更低的存儲和傳輸成本。

帶寬成本：在有限帶寬下H.265能傳輸更高質(zhì)量的網(wǎng)絡(luò)視頻，理論上，H.265最高只需H.264編碼的一半帶寬即可傳輸相同質(zhì)量視頻。更低的帶寬可以更好的降低存儲及傳輸成本，并為未來基于短視頻及直播領(lǐng)域更多更復(fù)雜好玩的互動玩法做鋪墊。

轉(zhuǎn)碼成本：但是當前主流瀏覽器均不支持H.265原生視頻播放，因此通常視頻生產(chǎn)端需要針對瀏覽器做一次H.264視頻的轉(zhuǎn)碼來適配瀏覽器端如PC場景的播放，而增加了轉(zhuǎn)碼成本。如在淘寶直播中，假設(shè)以每天5萬場直播計算，每場直播轉(zhuǎn)碼成本20元，一天就是100萬的轉(zhuǎn)碼成本。 為此，我們團隊對瀏覽器端H.265視頻播放的可行性及兼容性進行了一次探索，為移動端及PC端全量H.265做準備，也對瀏覽器端視音頻處理、WebAssembly實踐進行一次深入的嘗試。

H.264 vs H.265

H.264是當下用的最為廣泛的視頻編碼格式，H.265標準圍繞著現(xiàn)有的視頻編碼標準H.264，保留原來的某些技術(shù)，同時對一些相關(guān)的技術(shù)加以改進。新技術(shù)使用先進的技術(shù)用以改善碼流、編碼質(zhì)量、延時和算法復(fù)雜度之間的關(guān)系，達到最優(yōu)化設(shè)置。H.265和H.264都是基于塊的視頻編碼技術(shù)，主要的差別在于編碼單元的大小以及一些編碼算法細節(jié)，H.265將圖像劃分為“編碼樹單元(coding tree Unit, CTU)”，而不是像H.264那樣的16×16的宏塊。根據(jù)不同的編碼設(shè)置，編碼樹單元的尺寸可以被設(shè)置為64×64或有限的32×32或16×16。一般來說區(qū)塊尺寸越大，壓縮效率就越好。具體的算法及相關(guān)細節(jié)這里不具體展開了，還有一些其他的壓縮算法如因為H.265專利限制而生的開放編碼格式如AV1等，讀者可以參考其他相關(guān)文章。

如下圖，可以看到同樣主觀畫面質(zhì)量，H.265(500K)僅需H.264(800K)一半左右的帶寬碼率。

瀏覽器現(xiàn)狀

如下圖，因為H.265專利及硬解支持情況不完善的原因，主流現(xiàn)代瀏覽器均不兼容H.265編碼的視頻播放（Edge新版本以插件方式支持），但是因為Apple對H.265的支持（這里作者認為這可能是一個很重要的標志，因為技術(shù)的發(fā)展很多時候不光是這個技術(shù)本身所決定的，而是很多因素共同作用的結(jié)果，商業(yè)也是其中很重要的一個因素），移動端ios safari在11.0版本以上支持原生播放。

想要在瀏覽器端播放H.265視頻原生的<video />標簽沒有辦法支持，但是因為視頻格式本身是連續(xù)圖像畫面和音頻的集合，參考了chromium的源碼及video標簽內(nèi)部的實現(xiàn)原理，可以通過<canvas /> + Web Audio API 的結(jié)合來模擬實現(xiàn)一個虛擬的video標簽來實現(xiàn)播放器功能。

Demo

因為直播流時效性的緣故，發(fā)布了一個播放H.265 mp4視頻（該視頻地址直接在瀏覽器中播放只有聲音而沒有畫面）的在線Demo，讀者可以有一個直觀感受。

地址：

https://g./videox/mp4-h265/1.0.2/index.html

效果

前期調(diào)研

播放器整體架構(gòu)

基于傳統(tǒng)播放器的架構(gòu)，我們設(shè)計的播放器架構(gòu)如下：

視音頻基礎(chǔ)

因為前端領(lǐng)域?qū)σ曨l領(lǐng)域的涉及場景不多，一個<video />標簽就可以滿足大部分場景，但是經(jīng)歷了這幾年直播和短視頻的爆發(fā)，視頻的需求和功能也變得越來越復(fù)雜，開發(fā)之前閱讀了很多視音頻領(lǐng)域相關(guān)的書籍和文章，在此先對視音頻基礎(chǔ)進行一個簡單的介紹。

視頻中我們通常說的視頻的格式，比如 .mp4, .mov, .wmv, .m3u8, .flv 等等被稱為container。在一個視頻文件中音頻、視頻數(shù)據(jù)是分開存儲的，使用的壓縮算法也不一樣。其中container作為容器主要包含了video數(shù)據(jù)、audio數(shù)據(jù)、metadata（用于檢索視音頻payload格式等信息）。每個格式的封裝格式不一樣，比如FLV格式的基本單元是Tag，而MP4格式的基本單元是Box，輔助的meta信息用于檢索找到對應(yīng)的原始數(shù)據(jù)。

而平時聽到的H.264, H.265等視頻編碼標準被稱為codec (COmpress and DECompress )。一個視頻格式比如mp4可以使用任何標準化的壓縮算法，這些信息都會被包含在一個視頻文件的meta信息中來告訴播放器該用什么編解碼算法來播放。

客戶端播放器

一個傳統(tǒng)的客戶端播放器播放一個視頻流經(jīng)過了如下各個環(huán)節(jié)：

拉取數(shù)據(jù) => 解封裝 => 音視頻解碼 => 采樣/像素數(shù)據(jù)發(fā)送到設(shè)備進行渲染。

client

對于流媒體，播放器客戶端通過拉流以數(shù)據(jù)源（音視頻流）為中心，進行管道式的傳輸。在此期間，對視頻流的讀取，轉(zhuǎn)換，分類，復(fù)制等一系列操作處理，以封裝的mp4流為例，需要對流進行解封裝、解碼、渲染等步驟：

瀏覽器video標簽

在探究的過程中，為了了解主流瀏覽器不支持H.265視頻播放的原因，以及瀏覽器端實現(xiàn)播放器原理的了解，通過對Chromium瀏覽器官方文檔及video標簽實現(xiàn)源碼的閱讀，整理了一個流程圖。

可以看到瀏覽器內(nèi)部對視頻流播放的實現(xiàn)，在經(jīng)過了PipelineController等數(shù)據(jù)傳輸管道的處理后利用FFmpeg軟解或者Gpu硬解之后交給視頻設(shè)備及音頻設(shè)備進行同步及渲染。其中H.265的視頻因為硬解支持情況不完善，軟解可能有性能風(fēng)險，所以在chrome中被關(guān)閉了不支持，在chromium中可以通過參數(shù)打開。我們就依照這個思路，利用瀏覽器提供的接口來實現(xiàn)一個模擬的video標簽。

設(shè)計過程

開發(fā)思路

開發(fā)思路按照從簡單到復(fù)雜的過程，對任務(wù)進行拆分，來完成H.265視頻點播及直播等各個場景的覆蓋，以mp4短視頻出發(fā)完成播放流程，再覆蓋直播場景，考慮如網(wǎng)絡(luò)抖動、內(nèi)存控制等復(fù)雜因素，再針對直播m3u8等回放文件進行播放并開發(fā)視頻seek、倍速等功能。

mp4播放=>flv播放=>hls播放=>加入seek、倍速等功能

可行性分析

• 思路：在最開始進行可行性分析時，參考結(jié)合了已有工具videoconverter.js和libde265.js對H.265視頻ffmpeg的編譯提取了hevc文件及mp3音頻文件在瀏覽器端進行了播放。

• demo地址：https://sparkmorry./mse-learning/h265/

• 表現(xiàn)：將720P的mp4視頻進行視頻和音頻的分離，通過 <canvas /> 繪制圖像，通過 <audio /> 標簽播放音頻，畫面在Macbook Pro上Chrome瀏覽器下在23fps左右。

• 問題：

• 不能達到解碼性能標準: 720P的視頻在Macbook Pro上僅在23fps左右，而原視頻是25fps，不能達到解碼性能標準，無法流暢播放。

• 無法做到音畫同步: 該方案因為直接提取了hevc裸流文件，無法獲取視頻和音頻每幀的pts時間戳，無法做到嚴格的音畫同步。

• 解決方案：

• 性能：因為libde265.js是asm.js，通過對libde265.js開源庫的改造，打包WebAssembly測試性能情況

• 音畫同步：參考flv.js、hls.js等開源視頻庫的方案，根據(jù)曾經(jīng)的實踐經(jīng)歷，js在解封裝方面的性能能夠完成視頻流文件解封裝，獲取每幀視頻、音頻播放的pts及原始數(shù)據(jù)交給解碼器進行解碼再渲染。

• 方案調(diào)整：

MP4點播流播放

• 思路：根據(jù)上一過程調(diào)整的解決方案，通過js對mp4流進行解封裝，因為音頻解碼的復(fù)雜度不高，也先用js進行解碼，僅將視頻解碼模塊用已有的三方模塊libde265并替換為wasm解決性能問題，音視頻解碼模塊都自身維護一段緩存區(qū)，負責(zé)存儲解封裝模塊傳過來的packet數(shù)據(jù)，解決音畫同步的問題。

• 表現(xiàn)：通過開源libde265實現(xiàn)的視頻解碼模塊，針對于720p的視頻流，平均解碼時間是45ms，不能滿足每一幀音頻播放時間間隔（40ms）。

• 問題：視頻解碼性能仍然不夠。

• 解決方案：

• 丟幀：保證了音頻同步，丟掉部分非參考幀，但損失了部分體驗。所以提升解碼性能和改善播放策略才能有可能滿足當前方案的可行性。提升解碼性能和改善播放策略。

• 提升解碼性能：用解碼性能更好的ffmpeg替換掉libde265。

• 改善播放流程：因為每個requestAnimationFrame循環(huán)任務(wù)都是同步的，邊解碼邊播放。引入用WebWorker線程。通過改善視頻解碼模塊，解碼器內(nèi)部開啟循環(huán)解碼，當外部的視頻播放設(shè)備需要播放下一幀時，直接從解碼器解碼完的幀緩存中讀取下一幀數(shù)據(jù)。實現(xiàn)了worker和主線程并行執(zhí)行。

• 方案調(diào)整：

• demo地址：https://static-assets./h265/index.html

• 設(shè)計流程 

FLV直播流播放

• 思路：mp4視頻流暢播放，但在直播場景（如FLV視頻流）中，客戶端需要和服務(wù)端建立長鏈接，不斷接收流消息，借用FFmpeg本身對流媒體的支持，對視頻數(shù)據(jù)進行解封裝及解碼。

• 表現(xiàn)：無法編譯FFmpeg網(wǎng)絡(luò)庫，TCP無法建立連接。

• 問題： 無法編譯FFmpeg網(wǎng)絡(luò)庫：TCP建立連接創(chuàng)建Socket時報錯，Emscripten工具無法編譯TCP連接相關(guān)配置 codec不支持：FLV官方協(xié)議不支持H.265。

• 解決方案：

• 無法編譯FFmpeg網(wǎng)絡(luò)庫：主線程利用fetch方法進行拉流，放到FFmpeg自定義緩沖區(qū)進行解封裝及解碼。因為直播流長時間播放需要不停的開辟、釋放內(nèi)存空間，采用環(huán)形的數(shù)據(jù)緩沖區(qū)。

• FLV官方協(xié)議不支持H.265：對FFmpeg及編碼端對H.265進行擴展，因為FFmpeg內(nèi)部數(shù)據(jù)結(jié)構(gòu)嵌套較深，替換js解封裝函數(shù)直接用FFmpeg的解封裝函數(shù)。

• 方案調(diào)整：

• 設(shè)計流程

當前方案

播放流程

1. 因為FFmpeg支持多種格式解封裝，只需要在在主線程中通過瀏覽器API（通常是fetch方法）拉取原始流數(shù)據(jù)并放到緩存中，等初始緩存到一個閾值時開啟Worker進行解封裝及解碼；

2. 在子線程（Worker）中通過主線程fetch方法觸發(fā)的數(shù)據(jù)回調(diào)接收數(shù)據(jù)存入環(huán)形緩沖區(qū)（內(nèi)存環(huán)）中；

3. 子線程將讀取到的音頻幀輸送到主線程中，通過Web Audio API緩存音頻數(shù)據(jù)，根據(jù)已解碼的視頻幀緩存隊列循環(huán)解碼保證緩存中一直緩存10幀rgba圖像數(shù)據(jù)；

4. 主線程中canvas根據(jù)音頻播放回調(diào)的pts消費并渲染視頻圖像；

5. 循環(huán)以上操作直到fetch接口返回流已結(jié)束。

解碼器編譯

通過Emscripten工具可以把C語言編寫的FFmpeg庫編譯成wasm并在瀏覽器中應(yīng)用到視音頻解碼中。

我們的視頻解碼場景和通常的播放器一樣，通過依賴FFmpeg的通用接口來實現(xiàn)解封裝和解碼的工作。先通過emscripten編譯ffmpeg庫，再通過靜態(tài)庫的方式依賴到解封裝和解碼入口程序中。

測試表現(xiàn)

性能測試

測試視頻

因為flv直播視頻受時效性影響較大，拿720P高清的H.265 mp4視頻作為穩(wěn)定輸入測試

地址：

https://gw./bao/uploaded/LB1l2iXISzqK1RjSZFjXXblCFXa.mp4?file=LB1l2iXISzqK1RjSZFjXXblCFXa.mp4

視頻參數(shù)：

測試機器

• lenovo ThinkPad T430

• CPU: Intel(R) Core(TM) i5-3230M CPU@2.60GHz x64處理器

• 內(nèi)存: 8 GB

• 系統(tǒng): windows 10

• MacBook Pro (Retina, 15-inch, Mid 2015)

• CPU: 2.2 GHz Intel Core i7

• 內(nèi)存: 16 GB

• 系統(tǒng): macOS 10.14.2

性能情況

• MBP下表現(xiàn)

• 針對兩個pc筆記本進行了測試，平均每幀解碼（包含yuv420轉(zhuǎn)rgba）時長在各個瀏覽器的表現(xiàn)情況如下： 注：此處Native（原生）表示針對mac系統(tǒng)原生編譯的FFmpeg作為依賴的解碼器（相對不考慮具體如x86、arm等計算機架構(gòu)的WebAssembly的跨平臺方案而言）。

意味著最高能提供720P高清視頻如下幀率視頻流暢播放的能力：

可以看到這兩臺機器中，在非高速運動等普通的如電商場景25fps幀率的高清720p視頻已經(jīng)能達到生產(chǎn)環(huán)境的標準，但是距離原生的速度還有一定距離。

瀏覽器兼容性

主要用到了WebAssembly及WebWorker的支持，實際測試中主流瀏覽器Chrome、Safari、Firefox、Edge均能通過兼容性測試。

• WebAssembly

• WebWorker

ToDo

當前的技術(shù)方案已經(jīng)能在大部分機器的主流瀏覽器上流暢的播放720P的高清直播流，但是在Edge瀏覽器及性能稍差的機器上還是存在高清視頻解碼性能不能滿足流暢播放的風(fēng)險，針對WebAssembly達到native速度的目標還有一定距離，尤其是匯編并行計算的支持，在視音頻及大規(guī)模數(shù)據(jù)處理中是很常見的性能優(yōu)化策略，作者整理了幾個優(yōu)化的方向，在未來還有更多探索的空間：

• 匯編

  FFmpeg中解碼有較多利用匯編進行并行計算的優(yōu)化，但是匯編指令是cpu specific的（比如x86指令和arm指令），而wasm是跨平臺的基于棧的虛擬機。Emscripten不支持匯編的編譯，考慮用clang等llvm前端將FFmpeg的.c和匯編.asm文件編譯成LLVM IR（LLVM Intermediate Representation），然后通過fastcomp或者其他后端來編譯測試。

• 硬解

  FFmpeg3.3以上開始支持自動硬解探測，支持的硬件設(shè)備根據(jù)不同操作系統(tǒng)及硬件會有不同的支持，具體參考：https://trac./wiki/HWAccelIntro 。因為wasm是跨平臺的虛擬指令集，支持程度還要待進一步探究。

• 多線程

  FFmpeg內(nèi)部解碼有多線程來提高解碼性能，通過pthread可以支持跨平臺的多線程支持的，但是如果不支持共享內(nèi)存，則線程之間的數(shù)據(jù)傳輸會有很多性能消耗（深拷貝或者Transfered Object）。瀏覽器端共享內(nèi)存通過SharedArrayBuffer來實現(xiàn)，因為有安全隱患，大部分主流瀏覽器關(guān)閉了SharedArrayBuffer、Chrome67+開始恢復(fù)?？紤]到兼容性多線程的支持還要再進行嘗試。

• WebGL渲染

  解碼平均時長中有4ms左右(15%)在yuv轉(zhuǎn)rgba上，通過WebGL可以用gpu加速圖像的計算，但是同時與WebGL的數(shù)據(jù)交換又會產(chǎn)生一定的性能損耗，需要再測試查看性能結(jié)果

未來展望

通過H.265視頻播放將開源視音頻庫FFmpeg的能力及WebAssembly性能的優(yōu)勢在瀏覽器端視音頻處理上有了一次深入的嘗試。視頻作為一種多媒體形式，相比現(xiàn)有的文字、圖像、音頻都能有更生動及更豐富信息的表現(xiàn)。尤其經(jīng)過了直播和短視頻的爆發(fā)增長后，成為了一種基礎(chǔ)的多媒體形式，也是網(wǎng)絡(luò)及移動端手機性能等技術(shù)發(fā)展的體現(xiàn)。未來隨著5G及更高性能的硬件設(shè)備的發(fā)展會被更廣泛的應(yīng)用到各個領(lǐng)域。瀏覽器在這場視頻革命中也是不可或缺的一個環(huán)節(jié)，通過這次的探索，為未來瀏覽器端擴展視音頻處理的通用能力提供了想象的空間，同時也在瀏覽器端通過WebAssembly向native性能及能力靠近的路上做了一個落地的嘗試，雖然從測試情況看現(xiàn)在的表現(xiàn)還不如native，但是隨著標準及技術(shù)的演進，為未來對性能要求比較高的圖形圖像及人工智能等相關(guān)方向在瀏覽器端處理一定會漸漸被廣泛的應(yīng)用起來，比如如下幾個方向：

• 擴展瀏覽器端視頻播放能力

  借助FFmpeg強大的編解碼能力，除了H.265視頻的播放，未來還可以在瀏覽器端兼容各種格式及編碼類型的視頻播放。如不同的編碼格式AV1、不同的容器格式mov格式等等。

• 擴展瀏覽器端視音頻處理能力

  借助FFmpeg及其他語言框架的現(xiàn)有能力，還可以在視音頻領(lǐng)域做更多復(fù)雜的操作如視頻濾鏡、視頻剪切、視頻格式轉(zhuǎn)換等功能，減少網(wǎng)絡(luò)傳輸及存儲的成本。

• 基于WebAssembly的高性能web應(yīng)用

  借助WebAssembly的跨平臺優(yōu)勢，可以將傳統(tǒng)的其他語言的開源框架如圖形相關(guān)開源庫OpenGL、SDL等的能力移植到瀏覽器上來。借助性能上的優(yōu)勢也可以將傳統(tǒng)的圖像、3D等運算能力要求較高的應(yīng)用擴展到瀏覽器端。

參考

• Chromium媒體元素源碼: https://github.com/chromium/chromium/tree/master/media

• WebAssembly:

  https:///

• 優(yōu)秀的開源視音頻處理框架FFmpeg:

  https://www./

• 基于LLVM編譯的WebAssembly打包工具集Emscripten：https:///index.html

• 基于WebAssembly的ogg播放器：

  https://github.com/brion/ogv.js

• 基于FFmpeg的簡單播放器：

• https://github.com/leixiaohua1020/simplest_ffmpeg_player

點擊【閱讀原文】或掃描圖中二維碼了解LiveVideoStackCon 2019 上海 音視頻技術(shù)大會 最新日程信息。