與Google、蘋果和微軟不同，Mozilla的Firefox并沒有龐大的生態系統照看和支持。不過這并不能妨礙Firefox Quantum取得廣泛的好評。Firefox的擁躉瘋狂的支持這家擁抱開源、開放的科技公司。Mozilla也是AV1和WebRTC重要貢獻者，在LiveVideoStackCon 2018大會上，Google多媒體組的Zoe Liu稱贊了Mozilla的貢獻。

作為下一代免專利費、開源的編解碼器，AV1被認為將給互聯網上的多媒體開發和應用帶來廣泛影響。本文來自Mozilla研究主管Michael Bebenita，他在瀏覽器上實現了視頻流分析，幫助Codec開發人員快速分析性能，定位bug。LiveVideoStack進行了摘譯，點擊『閱讀原文』訪問原文鏈接。如果你有興趣利用業余時間為LiveVideoStack貢獻，歡迎申請成為的社區編輯，你可以通過LiveVideoStack微信公眾號內回復『社區編輯』了解詳情。

文 / Michael Bebenita

譯 / 蔣默邱澤

在Mozilla，我們一直在努力研究新一代AV1視頻編解碼器。AV1可比HEVC（H.265）和Google VP9提高25％的編碼效率，并由AOM開放媒體聯盟（ Mozilla & ATEME都是是其一部分）開發。

AV1事實上是VP9的衍生產品，現在還包括大量額外的編碼工具需要從Daala、Thor和VP10編碼導入進行測試實驗。這些實驗以意想不到內容形式和畫面復雜性產生互相作用，必須在各種各樣的畫面內容上反復測試，這可是很花時間的。單個視頻幀有時可能需要一個多小時的時間才能完成編碼，而且這只不過是我們日常測試的一小部分而已，我們編碼30個視頻剪輯，每個剪輯包含60幀。整個編碼過程是大規模并行的，并在AWS上運行，雖然使用了硬編碼，運行一個測試任務仍然可能需要幾個小時甚至幾天之久。

遺憾的是這種計算成本使得開發者不便于本地編碼和分析視頻流，但也揭示了一個有趣的現象。為什么不在云（或瀏覽器）中運行我們所有的分析工具呢？

我們的第一個嘗試就是使用流分析儀。分析儀解碼AV1數據流并顯示關于流信息的各種細節。這些信息可以幫助編解碼器工程師更輕松地識別和修正bug。分析儀的輸入通常很小（一個編碼比特流），但輸出流非常大。例如：一個1080p的視頻幀產生4MB的原始圖像數據和大量的分析元數據。如果分析儀在本地運行，簡直小意思，但是若是分析儀在遠程服務器上運行，則帶寬尤其是延遲會很致命。

理想的解決方案是直接在瀏覽器中運行分析儀。為此，我們需要將分析器和編解碼器移植到JavaScript中（幸運的是要感謝Alon Zakai，為我們提供一個工具Emscripten可以幫助我們），并在瀏覽器中運行它。

分析器由兩個組件組成：decoder.js，它是編解碼器的Emscripten編譯版本和基于HTML的UI前端。 要分析一個視頻，我們只需要指定一個視頻文件（采用* .ivf格式）和一個適當參數的decoder.js文件來解碼它。

analyzer.html?decoder=decoder.js&file=a.ivf&file=b.ivf

在上面的鏈接中，analyzer.html加載解碼器，并用它解碼2個碼流a.ivf和b.ivf。或者也可以使用多個解碼器來分析視頻：

analyzer.html?decoder=aDec.js&file=a.ivf&decoder=bDec.js&file=b.ivf

這種方法的優點在于你可以輕松共享鏈接到解碼的視頻，而且所有這些都在瀏覽器中運行，無需維護任何服務器基礎架構。對于提交給AreWeCompressedYet.com（AWCY）的編解碼器的每個修訂版，都會自動生成解碼器JavaScript文件方便它們可公開訪問。

你可以按照以下步驟實現：

參考這里：http://aomedia.org/contributor-guide （如果你想幫忙，我建議你參照這樣做）

查看與要分析的編碼視頻兼容的編碼解碼器的特定修訂版本。

構建并運行假想的本地分析程序。

如果你想分享一些分析結果，截圖并分享，或者要求同時重復第1步到第3步。當然，他們不太可能這樣做，因為它不止一次點擊那個文檔。

也許我是在一家瀏覽器公司工作，所以我可能會有偏見，但我認為這是最好基于網絡分析方式。

Emscripten通常用于將游戲或C / C ++庫移植到網絡上，這實際上并沒有什么大不了，但如有稍微的差別也許是我從未測試過而已哈。我們使用Emscripten來使我們的持續集成構建控件可運行和可分享，這是有多酷？超便利打敗本地分析！！

玩轉分析器

所以讓我們用碼流分析來看看，下面我們將比較這兩個流：crosswalk_10.ivf和crosswalk_60.ivf。這兩個視頻采用相同版本的編碼器進行編碼，分別為10和60 QP（數量越少，質量越高）。分析器將塊的細節可視化為一組疊層來觀察。

人行橫道 第1幀@10 QP

人行橫道 第1幀@60 QP

塊拆分層

AV1中的最大塊大小為64x64，最小為4x4。（有實驗說可以擴展這個范圍。）編碼器使用大量的因素來決定如何遞歸地劃分64x64塊。但總的來說，我們可以從下面的圖片中看到，細節更多的區域的塊大小更小，細節更少的區域的塊大小更大。在質量較低的設置中，平均塊大小比較大些，但只適用相同的一般情況下。塊的大和小很重要，因為這是編碼器跳過信號信息，運動矢量，預測模式，變換類型和其他類型信息的水平。塊尺寸越小，編碼器可以發送的信息越多，但這也意味著編碼器會消耗更多的比特位來顯示這些細節。

塊拆分情況-人行橫道 第1幀@10 QP ?

塊拆分情況-人行橫道 第1幀@60 QP

視頻的第一幀是一個幀內幀（Intra-frame coding），這意味著每個塊是從它周圍的塊（從上至下）在空間上進行預測的。視頻的第二幀是一個幀間幀，這意味著它是從幀之前（或之后）的幀中暫時預測的。對于第二幀（下面）的塊拆分決定是有趣的，它們只反映在兩個幀之間變化的圖像區域。前景中兩個人的頭向右平移，所以改變的區域圍繞頭的輪廓。面部雖然向右移動，但不需要細顆粒度的塊，因為它可以從前一幀粗略地預測，而頭部周圍的區域反而不能。 ?

塊拆分情況-人行橫道 第2幀@60 QP

分析可以將每個塊大小所覆蓋的區域繪制成堆積條形圖。第一幀是這個視頻序列是唯一的，因為它是一個幀內幀。它使用大致相等數量的16x16,32x32,64x64塊。其余的幀都是幀間幀數，大部分使用64x64塊。有趣的是，這里有一個反復出現的現象。第8幀、16幀、24幀塊中似乎沒有32x32塊。我很想知道為什么？這些應該分析器要發現的問題。這有可能是編解碼器的正常操作行為，也可能是一個錯誤導致。

塊拆分情況 - 人行橫道畫面，共32幀@ 60 QP

在10QP，這看起來不同，但有點類似。

塊拆分情況 - 人行橫道畫面，共32幀@ 10 QP

預測模式層

每個塊都有一個預測模式。對于內部幀，這些包括定向預測模式，在每個塊內繪制為細線。彩色塊使用DC_PRED（粉紅色）和TM_PRED（藍色）。

幀內預測模式 - 人行橫道畫面，第1幀 @ 60 QP

如果通過點擊中心來放大中心女士的眼睛，我們可以清楚地看到這些編碼決策最終產生的預測模式和編碼偽像。如下圖

幀內預測模式 - 人行橫道，第1幀 @ 60 QP

幀內預測模式偽影 - 人行橫道，第1幀 @ 60 QP

幀間幀沒有方向預測模式：白色（NEWMV），藍色（NEARMV），紫紅色（NEARESTMV）和紫色（ZEROMV）。 ?

國際預測模式 - 人行橫道畫面，第2幀 @ 60 QP

塊信息詳細信息

您可以通過點擊獲得有關塊的更多信息。例如，點擊左上方的紫色塊（0x0）顯示以下塊詳細信息

這是方便的方法來弄清楚什么顏色的意思。

運動矢量圖層

幀間的塊可以從其他幀預測。每塊可以有2個運動矢量在這里顯示為紅線和藍線的組合。顏色的強度代表矢量的大小。每個矢量都是可以預測塊內容的偏移量。矢量越長，運動就越多。

?運動矢量 - 人行橫道畫面，第2幀 @ 60 QP

位統計層

在AV1中，無論何時從比特流中讀取符號，解碼器都跟蹤用于表示該符號的比特數。位記帳信息具有塊級上下文，這意味著分析器可以確切地確定在每個符號類型的塊上花費了多少位。在下表中，該位計費信息被聚合在整個幀上：458個read_mv_component符號采樣被讀取，總計537比特或28.5%的量用于對幀進行編碼。

分析器還可以在多個幀中顯示聚合的比特信息。 這在比較兩個不同的位流時很有用。 這些圖表是特地安排的，這樣它們在視頻之間切換時不會移動，以便更容易發現差別。

數據統計信息也可以作為圖層顯示。突出顯示的紫色區域表示幀內的位層深度分布。

位層 - 人行橫道畫面，1 幀 @ 60 QP

下圖禁用圖像使位輪廓計算層更清晰一些

位層 - 人行橫道，1幀 @ 60 QP

如果我們進入第二幀，我們將會會看到更明亮的彩色區域。默認情況下，顏色比例和強度是根據幀/像素的最大數量/像素數量來計算的。以下是可調整比例：

• 相對幀：默認情況下，這在分析單個幀內的位分布時非常有用。

• 相對視頻：在視頻序列中的所有幀上計算最大比特數/像素數。這在分析整個序列中的位分布時非常有用。

如果我們看到第二幀，我們會看到它有更亮的彩色區域。這并不意味著它使用更多的數據在里面，這只是意味著幀中的更多的數據量花費在圖像的較小區域塊。

當然顏色比例也可以調整，默認情況下分析儀使用具有透明度的熱點圖比例。藍色大多半透明，紅色區域不透明而已。

• 單色：單一顏色，透明。

• 熱點圖：默認情況下，熱圖與透明度的顏色比例。

位層 - 人行橫道畫面，2幀@ 60 QP

• 熱點圖（不透明）：熱圖顏色比例沒有透明度。 ?

位圖層 - 熱圖不透明情況 - 人行橫道，2幀@ 60 QP

位統計層還允許您根據符號類型進行過濾。這對于深入了解特定符號的數據位分布非常有用。例如，下面我們可以看到“read_mv”（讀運動矢量）符號的數據位分布。

位圖層 - 熱圖不透明 - 由“read_mv”過濾 - 人行橫道，2幀@ 60 QP

跳過標志圖層

跳過標志用來表示一個塊沒有系數。跳過的塊被繪制成藍色，從下面的圖片中可以明顯看出跳過的塊出現在大部分為空的圖像區域中。如果我們也覆蓋比特核算層，我們可以看到大多數比特花費在非跳過區域，這是可以預判的部分。

?

下一步還剩什么呢？

Emscripten解碼器其實使用起來足夠快了，但它可以優化的更快。在高位深度模式下編解碼器使用64位計算，需要在asm.js中模擬因為它缺少64位整數計算方式。我所知道影響性能約10%~20%。另一方面WebAssembly支持64位計算，一旦移植沒問題我們將切換到WebAssembly。

如你所愿，AV1有大量的SIMD代碼路徑。至少我們做法是禁用分析器架構中的所有SIMD。

如果您不想在瀏覽器中測量原始解碼性能，你可以試試這個基準測試鏈接。在我的機器上，Firefox需要512毫秒來解碼15幀，Chrome需要719毫秒和Safari更久需要 1044毫秒。

另外一個性能問題是YUV2RGB的轉換。這類代碼使用浮點計算，需要另外進行優化。

如果你想趁熱了解AOM進展請看下面這個視頻https://youtu.be/lzPaldsmJbk

LiveVideoStack 2018年春季招聘

LiveVideoStack是專注在音視頻、多媒體開發的技術社區，通過傳播最新技術探索與應用實踐，幫助技術人員成長，解決企業應用場景中的技術難題。如果你有意為音視頻、多媒體開發領域發展做出貢獻，歡迎成為LiveVideoStack的一員。我們正在招募商務助理，高級編輯，策劃編輯，課程經理。

通過job@livevideostack.com聯系，或在LiveVideoStack公眾號回復『商務助理』，『高級編輯』，『策劃編輯』，『課程經理』了解詳情。

總結

以上是生活随笔為你收集整理的在浏览器中分析AV1码流的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。