編者按：AV1視頻壓縮格式是由開放多媒體聯盟 (AOMedia)開發，並於2018年初最終確定。AV1具有功能強大的編碼算法，與其前身VP9相比，AV1的壓縮性能提升了30%以上。但是，AV1編碼器的複雜性也遠高於VP9編碼器。對此， LiveVideoStack特別邀請到了來自Google的王雲慶老師，爲我們分享介紹AV1編碼器的優化以及其在流媒體和實時通訊中的應用。
文/王雲慶
整理/LiveVideoStack
大家好，我是王雲慶，從清華畢業後到美國獲得Computer Science的碩士。我從2007年開始做視頻壓縮有關的工作，在Google工作了十多年。現在的主要工作是AV1編碼器的優化。
我今天要分享的題目是AV1編碼器的優化及其在流媒體和實時通訊中的應用。
我們分四個部分來講：首先簡單介紹一下AV1；然後講一下VOD的encoding，也就是在視頻點播中的編碼；第三，我們討論實時通訊中AV1的編碼；最後，我們做一個總結。
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也是開源的，有興趣大家可以看一看。
02 VOD 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還可以提高。這就進一步提高了多線程編碼器的性能。
03 RTC 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代碼熟悉的話，應該會看到最近編碼器性能有很大的提高。從去年到今年，我們的目標是繼續優化，希望能夠提供一個非常快的實時編碼器，而且這個編碼器還能提供良好的視頻壓縮率。最後，libaom AV1是一個開源的代碼庫，歡迎大家使用、測試，如果可以的話，歡迎大家的參與和貢獻。
以上就是我的全部分享內容，謝謝大家！