Web 端 H.265 播放器，技術可行性以及效能測試
#video #WebAssembly
背景
最近公司大佬提出讓前端做攝像頭視訊的解碼，這樣可以節省後端的轉碼資源開銷，同時降低延遲。另外 AI 標註團隊也有解碼需求，需要解碼視訊幀做標註處理，所以順勢研究一下如何在前端實現視訊解碼功能。文章大多數內容均為網際網路摘抄，本文亦是為做內部分享，如有侵權請聯絡我刪除。後續會不斷更新一些資訊
H.265 介紹
H.265 又稱 HEVC(全稱 High Efficiency Video Coding，高效率視訊編碼)，是 ITU-T H.264/MPEG-4 AVC 標準的繼任者。相比 H.264，H.265 擁有更高的壓縮率，也就意味著同樣 ** 位元速率 **（又稱位元率是指每秒傳送的位元 (bit) 數。單位為 bps(Bit Per Second)，位元率越高，每秒傳送資料就越多，畫質就越清晰），H.265 的畫質會更清晰，更高的壓縮率就能使用更低的儲存和傳輸成本。
H265 的特點
- ** 頻寬成本 **：在有限頻寬下 H.265 能傳輸更高質量的網路視訊，理論上，H.265 最高只需 H.264 編碼的一半頻寬即可傳輸相同質量視訊。更低的頻寬可以更好的降低儲存及傳輸成本，併為未來基於短視訊及直播領域更多更復雜好玩的互動玩法做鋪墊。
- ** 轉碼成本 *：但是當前主流瀏覽器均不支援
H.265原生視訊播放，因此通常視訊生產端需要針對瀏覽器做一次H.264視訊的轉碼來適配瀏覽器端如 PC 場景的播放，而增加了 * 轉碼成本 **。如在淘寶直播中，假設以每天 5 萬場直播計算，每場直播轉碼成本 20 元，一天就是 100 萬的轉碼成本。
為此，我們團隊對瀏覽器端H.265視訊播放的可行性及相容性進行了一次探索，為移動端及 PC 端全量H.265做準備，也對瀏覽器端視音訊處理，WebAssembly實踐進行一次深入的嘗試。
H.265 和 H.264 都是基於塊的視訊編碼技術，主要的差別在於 ** 編碼單元的大小 ** 以及一些編碼演算法細節，H.265 將影像劃分為 “編碼樹單元 (coding tree Unit, CTU)”，而不是像 H.264 那樣的 16×16 的巨集塊。根據不同的編碼設定，編碼樹單元的尺寸可以被設定為 64×64 或有限的 32×32 或 16×16。一般來說區塊尺寸越大，壓縮效率就越好。具體的演算法及相關細節這裡不具體展開了，還有一些其他的壓縮演算法如因為 H.264 專利限制而生的開放編碼格式如 AV1 等。
相容性
所以想要直接原生在瀏覽器播放 H.265 基本是不靠譜的，只有移動端 Safari11 以及 Windows 下高版本的 Edge 、IE 支援支援。
實現方案
使用 WebAssembly 把 FFmpeg 編譯之後移植到瀏覽器環境中執行，直接使用 FFmpeg 來解碼視訊，轉為前端能支援的形式播放，具體到實際一般就是 Canvas 繪製視訊幀 + Audio 播放語音，需要注意的是 Canvas 需要和 Audio 同步，否則會出現音畫不同步的問題，同時可能需要呼叫 WebGL 加速渲染（H.265 在轉碼後有一個渲染到 Canvas 的過程，可以使用 WebGL 加速）。
效能情況
測試機器：
MacBook Pro (Retina, 15-inch, Mid 2015)
- CPU: 2.2 GHz Intel Core i7
- 記憶體: 16 GB
- 系統: macOS 10.14.2
測試視訊：
Stream #0:0(und): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv, bt709, progressive), 1280x720, 854 kb/s, 25 fps, 25 tbr, 12800 tbn, 25 tbc (default)
decoder.wasm(ffmpeg)：1.4m
decoder.js: 168k
** 平均每幀解碼時長 *: 26ms
* 記憶體佔用 *: 24m
*cpu 佔用 **: 17%
decoder.wasm 過大可以採用動態載入的方式，需要播放視訊的時候再遠端獲取，但是存在 CPU 佔用過高的問題，i7 需要佔用 17% cpu，i5 需要 2-30%，i3 基本是 50%+ 的佔用。平均每幀解碼時長也遠超原生解碼，原生解碼大約 5ms 一幀，不過 26ms 也基本能保持 25 幀以上的幀率。
本作品採用《CC 協議》，轉載必須註明作者和本文連結