業務介紹

web投稿頁是B站的主要投稿來源，有很多高粉UP主使用web端進行投稿。

封面部分是投稿過程中耗時占比較高的步驟，因此在過去，web投稿頁已上線了自動的封面截取&推薦功能，有效提升了用戶體驗。同時在此過程中有了一定的技術積累。

自動封面功能依賴于對用戶上傳視頻進行截幀的能力，最簡單的方式是在上傳完成之后由服務端進行視頻截幀并返回推薦的候選封面，但顯然這一步會有大量的等待時間，因此我們采用的是純前端視頻截幀能力。

實際上在web投稿頁有多處需要截幀的地方：

• 封面推薦：截取多張低清圖在前端進行AI打分，基于打分結果截取最多10張高清圖供UP主選擇
• 封面選幀：對默認推薦的幀不滿意，手動獲取準確時間點的幀畫面
• 分區&話題推薦：從視頻中截取多幀，打包上傳至后臺進行分析后返回推薦結果

圖片

圖片

過去方案

過去web投稿頁采取兩套視頻截幀方案，wasm優先，canvas兜底

現狀：截幀成功率97%左右，封面推薦耗時（去掉極端數據）

• 平均：8.4s
• 50分位：16s
• 90分位：19s

WebCodecs是什么

WebCodecs于21年9月份推出，是用于在web頁面上對音視頻進行底層操縱（如編解碼）的API。

WebCodecs是相對底層的API，準確來說是為有音視頻開發基礎的人準備的，對前端同學來說有一定的門檻。

在使用FFmpeg時可直接調用包裝好的方法，主要門檻在于wasm環境的配置和構建。而使用WebCodecs時則需要基于編解碼的原理手動實現功能。或許后續WebCodecs將會推出更加上層的API。

所以在進一步介紹WebCodecs截幀方案之前，我想先介紹一些視頻處理的入門知識，感興趣的可以參考附錄中的鏈接進一步學習。

MP4的入門知識

視頻處理的基本概念

圖片

編碼/解碼：

• 視頻的編碼是將原始的圖像信息進行變換壓縮等處理，方便傳輸并保證圖像質量。解碼則是將壓縮后的文件還原成視頻需要的一連串圖像
• 常見的編碼格式：H.265; mpeg4; vp9 ……

封裝/解封裝：

• 一個視頻文件可能包含多個音頻和視頻流，通過封裝格式將他們聚合在一起，在使用時按照規則逐步解析
• 常見的封裝格式：mov,mp4,m4a,3gp,3g2; matroska; flv; avi ……

在這里簡單介紹下.mp4文件常用的h264編碼以及MP4封裝

編碼-幀內編碼（以JPEG圖片壓縮算法為例）

利用人眼的生物特性結合數學方法進行數據壓縮，并確保圖片質量。主要步驟：

圖片

具體流程在這就不展開了，總之，經過壓縮后圖片的文件大小將有非常顯著的縮小

圖片

??

圖片

原圖大小：1620*1080*3/1024/1204 = 4.25MB ----> 編碼后大小：856KB

PS：效果僅供參考，兩者皆為經過JPEG壓縮的圖片，只不過壓縮比不同

編碼-幀間編碼

盡管經過幀內編碼的壓縮，圖片已經有了很明顯的體積減少，但存儲視頻的每一幀是依然是很不明智的行為。因此需要幀間編碼。

通常有兩種方式進行幀間編碼：動態補償+幀間差異

動態補償

圖片

通常，兩個連續的幀之間是存在相同部分的，只是位置發生了變化因此可以通過存儲 塊的索引 + 偏移量（向量）以減少存儲體積

幀間差異

僅有動態補償還不夠還原每一幀的畫面，還需要通過兩幀之間的diff幀來輔助還原

圖片

diff幀的畫面通常信息量比較低，因此通過幀內壓縮會獲得很高的壓縮比

使用這兩種方法，結合上一幀參考幀，便可以獲得當前幀了

圖片

不同的幀類型

對應的，產生了三種幀類型

I 幀：俗稱的關鍵幀，僅使用了幀內編碼，可以被獨立還原為圖像

P幀：幀的圖像還原依賴前一幀的解碼結果

B幀：幀的圖像還原依賴前一幀與后一幀的解碼結果

圖片

幀的展示順序與解碼順序可能是不一樣的

封裝

MP4封裝文件基本結構：所有數據存放在box中

圖片

WebCodecs截幀方案

設想一個問題：只使用一個編程語言的基本API，如何最高效地獲取一個.mp4文件中的某一個時間點所在的圖像？

在了解了上面的基本知識后，我們可以分4步解決這個問題：

圖片

不同于播放器：截幀不需要預解碼緩存等步驟。為了保證性能，需要多少數據拿多少，拿多少處理多少，避免多余的文件讀取和解析造成性能和內存的浪費。

 元數據讀取&解析

1. 讀取文件頭部8byte的數據，按照box的header規則逐個獲取各box的位置以及大小

圖片

PS：moov可能在文件的末尾，順序不固定

2. 將moov box所在文件塊切片，提供給解封裝器解析，獲取到：

• 該視頻的詳細編碼參數
• 所有幀的索引信息

圖片

尋幀

策略：幀的時間戳并不是連續的的 → 某個時間點對應的幀可能并不存在 → 使用距離最近的幀

圖片

獲取到最近的關鍵幀和非關鍵幀之后，則要根據截幀的需求提供不同的文件塊給解碼器解碼

只提供關鍵幀速度更快，適合精度不高的場景（封面推薦），準確截幀適合精度要求高的場景（封面選幀）

整體過程

由于解封裝器(mp4box.js)和解碼器(WebCodecs-VideoDecoder)本身為流式設計，優先服務于流式的應用場景（如直播視頻流，點播視頻流，需要通過網絡請求分塊獲取到文件內容）。而視頻截幀是一個本地場景，已經有了完整的文件。且視頻截幀的API最好是類似同步的方式，在一個方法調用中完成所有的幀截取，并一起返回。

因此設計了通過事件拋出以及定時器機制以達到對內部流式依賴庫的包裝。

同時將計算密集的解封裝、解碼、渲染工作擋在獨立的web worker中執行，確保宿主頁面運行流暢不受影響。

性能分析

本地測試：

測試機上模擬了web投稿頁場景，對WebCodecs / WebAssembly / Canvas 三種截幀方式的性能進行了測試。

圖片

測試樣本：720p視頻2個，1080p視頻3個，2k視頻1個，4k視頻3個

測試環境：2020 M1 MacBook pro, 公司測試windows本（i5-1135G7 1.38~2.40GHz）

測試方式：在不同測試機上對每個視頻跑三次測試用例，共81次

測試用例：模擬web投稿頁截幀流程，數量，分辨率保持相同

實際場景中：視頻的編碼，分辨率，壓制參數等都會對截幀性能有影響，在這里以分辨率進行粗略的分類

線上數據：

圖片

圖片

總結：

• 隨著視頻規格的提升，webcodecs的截幀速度為wasm和canvas的 2.5~5 倍
• 提前 3~13s 完成頁面所需的截幀任務，用戶能夠更快的看到推薦結果
• 在內存消耗上有一定的降低

WebCodecs截幀方案的優點&缺點

優點

• 速度很快，受視頻規格影響小
• 讀取文件少
• 內存占用有一定降低，且表現穩定

缺點

• 依賴解封裝器的實現，當前使用了mp4box.js作為解封裝器，約能覆蓋95%的視頻
• 目前僅mp4和webm的解封裝器較完善
• WebCodecs瀏覽器支持性一般，當前為85%左右

規劃

• 作為web投稿頁首選截幀方式，根據線上表現做進一步優化
• 其他封裝格式的視頻支持：支持webm封裝格式（已支持，且開源了mkv demuxer）
• 開源

附錄

jpeg壓縮算法介紹：

• 我站：https://www.bilibili.com/video/BV1TZ4y1S7iG
• 知乎：影像算法解析——JPEG 壓縮算法 - 知乎（https://zhuanlan.zhihu.com/p/40356456）

視頻編碼介紹：https://www.youtube.com/watch?v=QoZ8pccsYo4

不同的幀類型：I, P, and B-frames - Differences and Use Cases Made Easy - OTTVerse（https://ottverse.com/i-p-b-frames-idr-keyframes-differences-usecases）

codec string的含義（[avc1.4d0033]代表什么）：Codecs in common media types - Web media technologies | MDN（https://developer.mozilla.org/en-US/docs/Web/Media/Formats/codecs_parameter#using_the_codecs_parameter）

MP4封裝類型介紹：mp4封裝格式各box類型講解及IBP幀計算 - 知乎（https://zhuanlan.zhihu.com/p/457888765）

在線MP4解析工具：Online Mp4 Parser（https://www.onlinemp4parser.com/）

WebCodecs官方說明：WebCodecs（https://w3c.github.io/webcodecs/#videodecoder-interface）

WebCodecs代碼示例：https://github.com/w3c/webcodecs

本期作者

張鋒嗶哩嗶哩資深開發工程師