01 Introduction：libaom AV1

我們先簡單看一下AV1。AV1是由AOMedia（開放多媒體聯盟）開發的，就是由多家公司聯合起來開發一種開源且沒有版稅的視頻編碼格式，AV1就是其第一代編碼格式。

AV1于2018年完成，在那個時候，AV1的編碼器復雜程度是非常高的。

但是AV1與它的前身VP9相比，如果在同樣的視頻質量條件下，它能夠提供超過30%的bitrate的節省，所以它的壓縮率還是非常高。

Libaom AV1是AV1的參考代碼，我把它的link放在了上圖，大家有興趣可以測試一下。



AV1增加了很多功能強大的壓縮工具，復雜性非常高，所以我們的目標就是優化AV1的編碼器，使得它能夠真正用在產品線上。

優化工作著重于以下兩個應用方面：

第一個是VOD的encoding。像YouTube這種編碼器一般都是離線進行，所以它對編碼器的速度要求沒有那么高，但是它對壓縮率的要求非常高；

第二種就是實時通訊的編碼。大家都知道實時通訊中要求非常快的實時編碼器，而AV1的優勢就在于它能夠允許在非常低的字節率的情況下進行視頻通訊，比如說Google的Duo是一個手機上面的視頻應用程序，它可以在20-30kbps這么低的字節率情況下實現手機上的視頻通訊。

這對一些新興市場的用戶來說是非常有用的，Duo在2020年就已經開始使用了。現在，我們下一個目標是Google的Chrome。WebRTC也是開源的，有興趣大家可以看一看。

02VOD encoding

第二部分我們介紹VOD的編碼。



這是一個簡單的AV1編碼器概述，第一個是預處理階段，其主要目的是rate control，就是怎么選擇frame或者block的quantizer；第二個階段是真正的編碼階段。

主要任務就是決定每一個block要選擇用什么樣的partition，mode，以及transform 等等；之后會對frame進行濾波，AV1支持三種In-loop的濾波器；最后一個階段要把Bitstream打包寫到一個文件中。

編碼器的整個過程中，絕大多數的時間花在了編碼階段。下面，我們就主要講一下這個階段的技術優化。



首先是Partition搜索。在AV1中，最大的塊尺寸是128x128，最小塊的尺寸可以到4x4。對每一個尺寸的塊，可以選擇10種partition的類型，例如：None，Split，Rectangular，及AB partition 類型。

所以說搜索空間是非常巨大的。我們主要用的方法是機器學習，就是建立ML模型，對每一種partition的尺寸和類型，我們可以決定是否要去評估它，還是可以略過它。

這樣就大大減少了搜索空間，達到非常好的優化結果。

下一步就是我們提到的mode，即prediction mode的決策。在AV1中，一個block的prediction mode選擇有超過150種。

理論上，評估一個mode的好壞要基于它的RD成本,成本越低則越好。mode決策，我們采用一個多級的方法。

在初始快速評估級，因為RD成本計算非常慢，我們就不去精確計算RD成本，而是用一個近似模型來估計出RD成本。

雖然RD成本的精度不高，也能夠快速排除一些非常不適合的mode。第二級評估中，我們進行RD成本的簡化計算，進一步排除很大一部分不適合的mode。

所以，只有幾個候選mode留下來。在最后一級，我們仔細評估每一個候選mode，最后通過它們的RD成本找出最好的mode。

AV1支持多種變換類型。我們在優化中間采用了機器學習的模型。基本思路是分析prediction之后的residue信號，通過分析找到有用的feature。如果這些feature跟最后變換的類型相關的話，就可以利用它們估計哪一種變換類型是比較適合的。通過這樣做優化，達到一個加速的結果。

我們簡單看一下AV1跟VP9的性能比較。對產品線上的應用，我們推薦AV1用speed2 到speed6。對VP9，我們推薦用speed1到speed4。這些編碼速度足夠快，而且提供很好的速度與壓縮率之間的平衡。上表中給出了AV1的speed2跟VP9的speed1的比較。我們用不同分辨率的一些視頻來做測試，采用了四種指標，即：AVG PSNR，Overall PSNR，SSIM還有VMAF。可以看到AV1的speed2相比較于VP9的speed1，平均可以給到超過30%的BD-rate的節省，在所有四種指標上都有這樣的表現。

在上圖中，我們把編碼器的速度也考慮進來，這里給出的數據都是單線程的結果。豎軸是BD-rate節省的百分數，是由前面提到的四種指標平均得到的。而橫軸是相對的編碼器時間。可以看到，上面這條曲線是VP9的speed1到speed4，下面的曲線是AV1的speed2到speed6。AV1 speed2的BD-rate的節省超過30%，但它的編碼時間差不多是VP9 speed1的六倍多，比較慢。再來看AV1的speed 5，它跟VP9的speed2的編碼時間基本上是一樣的，而且比VP9 speed2提供22%的更多的BD-rate節省。從這點上也可以看到，相比于VP9來說，AV1潛力更大，它能夠帶來的BD-rate的節省更多。

在編碼器中，為了能夠更好地加速，多線程的支持也是必不可少的。現在AV1編碼器中，我們有三級多線程的實現。首先，最直接的，是基于tile的多線程。在AV1中，tile都可以獨立的編碼和解碼。每一個tile中間，我們還有基于行的多線程。行之間的編碼不是獨立的。比如說，下面一行中的塊要開始的話，它上面一行右邊的塊應該先完成，所以有依賴性存在，在實現中要正確處理。上圖給出了一個簡單的多線程例子，這幅圖里一共有兩個tile，每一個tile有四行。我們會建一個job queue，把所有job放進來依次處理。“Tile+行”的多線程性能比單純只基于tile的多線程要好很多。

最近我們完成了frame并行處理 （FPMT）多線程。如果在“tile+行”的多線程之外，還有更多的線程可以用的時候，你可以再打開FPMT，這樣可以達到更好的效果。要使用FPMT，用戶要在編碼命令設置中打開它，即：“--fp-mt=1”。這樣，如果你設置的可使用線程足夠多的話，它就會啟動。

大家可能知道，在AV1編碼中，一個編碼單元是一組frame（即：GOP）。FPMT實現是基于AV1 GOP結構。

比如，AV1里比較常用的就是16個frame一組的GOP或者32個frame一組的GOP。這里我給了一個GOP=16的例子，我們來看表中最下面的一行，從frame 0開始，0是Key frame，下一幅是frame 16，叫做Alt-ref frame，然后再到frame 8、frame 4。

接下來，我們稍微改變了一下編碼的順序。本來frame 2下來是frame 1，frame 3，然后，frame 6，frame 5，frame 7。現在為了能夠并行處理這些frame，我們把frame順序改成2，6然后再做1、3、5、7。因為1、3、5、7都是leaf frame，可以被設置為non-reference frame，即：這些frame不會被用來作為別的frame的參考frame，所以對它們的編碼質量要求不高。

這樣的話，這四個frame可以并行處理，然后下一層的2和6也可以拿來并行處理。這樣的順序調整允許更多frame的并行處理，達到的效果會更好。

這里我們給出一個應用實例，來顯示編碼器多線程的scaling ratio。這是一個1080p和4K的視頻測試結果，我們用的tile是8個（2 rows x 4 columns）。對于4K視頻，可以看到，如果線程數足夠多，比如說16或者24的時候，多線程的速度是單線程速度的10倍，達到了很好的加速效果。

如果沒有FPMT的話，在線程到達一定數量的時候，scaling ratio就飽和了。有了FPMT，在有更多線程可以利用的時候，scaling ratio還可以提高。這就進一步提高了多線程編碼器的性能。

03RTC encoding

下面我們看一下實時通訊中的AV1編碼。就像我們開頭講的，在實時通訊的應用中，為了保證正常的視頻通話，編碼器的速度一定要非常快而且不能有延遲。所以，實時編碼不可能像VOD情況下可以用兩個甚至三個pass的編碼來達到好的壓縮效率，在這種時候，只能用一個pass的編碼，不能用任何lookahead frame，所以，基本上來一個frame就得立刻去處理它。

現在AV1的實時編碼器的速度范圍是speed5 到10。Speed 5和6共用了一些VOD代碼，壓縮率高，但也復雜一點。Speed 7-10是專用的實時代碼，所以會更快一些。

在多線程的支持上，主要是基于tile和基于行的多線程。因為不允許延遲，所以frame的并行在這里不實用。還有，AV1 RTC編碼器中支持scalable video coding（SVC），主要是spatial layers和temporal layers。 Rate control方面的話，對于RTC來講，因為沒有太多關于視頻frame的信息，所以多用constant bitrate（CBR），而且在AV1 RTC編碼器中還會支持一些adaptive quantization mode，比如：Background cyclic refreshing。

因為在視頻通話中，為了保證通話的平穩，單一frame編碼后的bitstream size不應該比平均frame bitstream size大太多。所以，這種情況下，我們采用了一個周期性的refreshing。比如，在每一個frame中選定某一個百分比的一些塊，而且這些塊會是后續的frame的參考。

這樣，我們就可以增加這些塊的bits，提高壓縮性能，但不會增大單一frame的bitstream size。這也是實時通訊編碼器與VOD編碼器設計上的不同。

這里給出AV1和VP9實時通訊編碼器的速度和BD-rate節省的一個比較。因為Google Meet 使用了VP9 speed7，所以我們這里用VP9 speed7作為baseline。可以看到，AV1的speed6能夠提供37%的BD-rate節省，但是相應的話，它的編碼器的時間會到五倍多，比較慢。

AV1 speed9和10已經跟VP9編碼器的時間類似，而且還可以提供13%到16%的BD-rate節省，所以從這里也能夠看出AV1的潛力還是更大一些。

下面就是一個簡短的總結。經過這幾年的優化，Libaom的AV1給VOD的應用提供了一個非常優秀的解決方案，希望我們的工作能夠促進AV1的廣泛應用，滿足用戶的所有需求。AV1 RTC編碼器優化還在持續地進行中，如果你對libaom AV1代碼熟悉的話，應該會看到最近編碼器性能有很大的提高。






審核編輯：劉清