AV1的編碼時(shí)間是x265和LibVPx的3倍左右

AV1最初發(fā)布時(shí)，編碼速度緩慢，時(shí)間過(guò)長(zhǎng)，嚴(yán)重影響編碼器的可用性。隨著不斷的優(yōu)化，其編碼時(shí)間已經(jīng)有很大改進(jìn)，幾乎可以使用。

2018年8月我首次測(cè)試AV1編碼時(shí)，其編碼速度非常緩慢，嚴(yán)重影響了編解碼器的潛在可用性。表1說(shuō)明了此事。除非另有說(shuō)明，否則所有編碼時(shí)間數(shù)據(jù)都依托于我的HP ZBook筆記本電腦（配置了單個(gè)2.8 GHz Intel Xeon E3-1505M v5 CPU）。此外，LibVPx是FFmpeg中VP9的實(shí)現(xiàn)，所有對(duì)AV1的引用都參考FFmpeg中可用的AV1編解碼器。

表1. AV1首次發(fā)布時(shí)的編碼時(shí)間

2018年末開(kāi)始，我曾寫(xiě)道，研究人員報(bào)告AV1編碼時(shí)間低至10倍LibVPx編碼時(shí)間。當(dāng)我最近開(kāi)始進(jìn)行一個(gè)編解碼器評(píng)估項(xiàng)目時(shí)，我很想知道這個(gè)時(shí)間是否匹配。我剛完成那個(gè)項(xiàng)目，表2顯示了現(xiàn)在的情況。我知道你在想，去年VMAF視頻壓縮質(zhì)量是96.18; 表2中引用的質(zhì)量是95.55。由于需要6個(gè)VMF點(diǎn)才能產(chǎn)生明顯的差異，即使是最敏銳的觀察者也不會(huì)注意到這個(gè).63差異。

表2. AV1當(dāng)前的優(yōu)化編碼時(shí)間

根據(jù)2018年8月對(duì)其他編解碼器的評(píng)測(cè)，AV1的編碼時(shí)間是x265和LibVPx的3倍左右。正如你將在下面看到的那樣，事情并不完全相同，而且我對(duì)其他編解碼器并不完全公平，但是盡管如此，它的加速速度還是相當(dāng)驚人，你不是這么認(rèn)為嗎?

如果你十分關(guān)心TL/DR，可以跳到表6并查看與其他編解碼器的比較。如果你想花時(shí)間了解我是如何做到那一步的，那就讓我們?cè)敿?xì)說(shuō)來(lái)。

編碼器速度的提升

在我們最初的測(cè)試中使用的命令字符串是這樣的:

如果對(duì)當(dāng)前版本的FFmpeg使用相同的字符串(我測(cè)試了N-93083-g8522d219ce版本)，編碼時(shí)間從226,080秒(45K乘以real-time)下降到18,196秒(約3,639倍real-time)，速度提高了約12倍。雖然仍然比x265慢63倍，比LibVPx慢80倍，但是我們可以看到表3中所示的結(jié)果。表3中創(chuàng)建的AV1文件的VMAF得分為95.91，因此與去年的96.18相比，質(zhì)量下降得非常小，而且不明顯。

表3.使用帶有當(dāng)前代碼的原始命令行（AOM的改進(jìn)）

表3顯示了我們初步測(cè)試的對(duì)兩者各方面表現(xiàn)的比較。所有其他編碼時(shí)間減少與編碼字符串的更改有關(guān)。

尋找AV1的最佳速度/質(zhì)量權(quán)衡

大多數(shù)編解碼器都有預(yù)設(shè)，可以讓你權(quán)衡編碼時(shí)間的質(zhì)量。例如，對(duì)于x264和x265，預(yù)設(shè)的名稱包括慢速、非常慢、快速、非?？旌椭械取Ｊ褂肁V1，預(yù)設(shè)通過(guò)cpu-usedswitch控制，你可以在上面的批次中看到我使用cpu-used8in pass 1和cpu-used0in pass 2。

如果在FFmpeg中加載AV1幫助說(shuō)明（ffmpeg -h encoder = libaom-av1），你將看到以下內(nèi)容：

使用LibVPx和AV1時(shí)，首次傳遞質(zhì)量不會(huì)影響第二次傳遞，因此你通常以最快/最低質(zhì)量設(shè)置運(yùn)行第一次傳遞。在Google的August First Look方向上，我以最高質(zhì)量運(yùn)行第二次傳遞，即cpu-used 0。編碼時(shí)間太慢，我沒(méi)有花時(shí)間嘗試這些設(shè)置，就像我之前對(duì)x264、x265和LibVPx做的那樣。

圖1顯示了在我開(kāi)始嚴(yán)格測(cè)試或生產(chǎn)編碼之前，我通常為每個(gè)編解碼器/預(yù)設(shè)/編碼器創(chuàng)建的圖表。紅線跟蹤可用質(zhì)量，而藍(lán)線跟蹤編碼時(shí)間。例如，在cpu-used5，編碼時(shí)間是最大值的6.63％（00:20:06與5:03:16相比），而質(zhì)量是最大值的99.64％（95.56 VMAF與95.91相比）。

圖1. AV1的質(zhì)量/速度曲線

如果你是一名研究人員，試圖度量某個(gè)特定編解碼器的絕對(duì)最佳質(zhì)量，你可以忽略該圖在cpu-used 0處編碼。如果你是一個(gè)視頻制作人，則可能使用cpu-used 5編碼，因?yàn)檩^低的設(shè)置可以節(jié)省最少的時(shí)間，而較高的設(shè)置可以最大限度地提高質(zhì)量。當(dāng)然，根據(jù)圖1中顯示的數(shù)字，如果你選擇使用cpu-use8，也沒(méi)有人會(huì)認(rèn)為你發(fā)瘋。假設(shè)你用cpu-used 5編碼，表4顯示了編碼時(shí)間的比較。

表4. 當(dāng)前版本的FFmpeg、cpu-used 5

單個(gè)五秒剪輯編碼能否準(zhǔn)確預(yù)測(cè)以多種數(shù)據(jù)速率編碼的更廣泛剪輯的質(zhì)量/速度曲線？在我最近完成的項(xiàng)目中，我在不同的編解碼器上使用相同的方法，基于5秒測(cè)試剪輯的單個(gè)編碼的曲線預(yù)測(cè)在預(yù)設(shè)使用和最大質(zhì)量（和預(yù)設(shè)切割）之間的質(zhì)量差異為1.3％編碼時(shí)間從18分鐘到3分鐘）。之后我測(cè)量了預(yù)設(shè)使用的和五個(gè)等級(jí)和六個(gè)測(cè)試片段的最大質(zhì)量之間的實(shí)際差異，實(shí)際差異為1.4％。因此，雖然更多數(shù)據(jù)總是更好，但單個(gè)編碼應(yīng)該是一個(gè)相當(dāng)準(zhǔn)確的預(yù)測(cè)器。

也就是說(shuō)，在我的“數(shù)字視頻編碼”一書(shū)中，我使用8個(gè)片段為x264，x265和LibVPx創(chuàng)建了類似的曲線，平均持續(xù)時(shí)間約為2分鐘。在我開(kāi)始使用新的編解碼器或編碼器（特別是AV1）進(jìn)行嚴(yán)格編碼之前，我會(huì)對(duì)類似的或更大數(shù)量的樣本進(jìn)行測(cè)試。

運(yùn)行多個(gè)線程

在最近的項(xiàng)目中，我咨詢了Google是否有其他方法可以加快編碼速度。一位工程師建議：

如果在運(yùn)行編碼器時(shí)可以使用多個(gè)線程，則有助于編碼器速度。對(duì)于高清及以上分辨率，我們建議使用區(qū)塊（tile）。使用區(qū)塊會(huì)導(dǎo)致質(zhì)量下降，我的舊測(cè)試顯示，使用2個(gè)區(qū)塊時(shí)損失約0.6％，使用4個(gè)區(qū)塊時(shí)損失約1.3％。

我自己沒(méi)有測(cè)試過(guò)4k的剪輯，所以我在這里給出一些建議。對(duì)于1080p，使用2個(gè)tile和8個(gè)線程：“--tile-columns = 1 --tile-rows = 0 --threads = 8

對(duì)于4k，使用4個(gè)tile和16個(gè)線程：“--tile-columns = 1 --tile-rows = 1 --threads = 16”（甚至嘗試：8個(gè)tile / 32個(gè)線程：“--tile-columns = 2 --tile-rows = 1 --threads = 32“）”

在該項(xiàng)目中實(shí)現(xiàn)區(qū)塊和線程之前，我測(cè)試了1080p和4K文件，這次是在我的HP Z840 40核工作站上，并使用了多個(gè)線程。我使用了建議的1080p設(shè)置，以及4K的第二組設(shè)置（--tile-columns = 2 --tile-rows = 1 --threads = 32）。表5顯示了結(jié)果。在1080p時(shí)，編碼時(shí)間下降了41.66%，而對(duì)于4K，編碼時(shí)間下降了70.56%，這兩種情況下的質(zhì)量差異可以忽略不計(jì)。

表5.在其他測(cè)試編碼中部署多個(gè)線程

應(yīng)用于ZBook測(cè)試平臺(tái)上的測(cè)試片段，部署--tile-columns = 1 --tile-rows = 0 --threads = 8 它們?cè)赾pu-used 5上的編碼時(shí)間從20:06下降到12:16，數(shù)字如表2所示。與此同時(shí)，VMAF指數(shù)也大幅下跌了0.01點(diǎn)(從95.56點(diǎn)跌至95.55點(diǎn))。

實(shí)際上，要清楚的是，添加到FFmpeg命令字符串的操作如下：

Google工程師顯示的設(shè)置很可能是獨(dú)立于FFmpeg工作的AOM編碼器。請(qǐng)注意，這些設(shè)置當(dāng)前不在AV1編解碼器的FFmpeg幫助文件中，但試一試，看看你是否得到相同的結(jié)果（注意：這些設(shè)置沒(méi)有記錄在我研究本文時(shí)檢查的舊版本的FFmpeg中，但是在FFmpeg中的當(dāng)前版本的AV1幫助文件中記錄了tiles，tile-columns，tile-rows和row-mt。）

雖然這些設(shè)置不會(huì)增加任何特定編碼運(yùn)行的編碼速度，但它們可能不會(huì)增加任何給定系統(tǒng)上的編碼吞吐量。這是因?yàn)樗鼈兯坪醪](méi)有提高編碼效率，就其本身而言，它們似乎允許每個(gè)單獨(dú)的編碼消耗更多的CPU資源，這在任何給定的系統(tǒng)上都是一個(gè)零和數(shù)字。

雖然數(shù)字沒(méi)有完美映射，但本質(zhì)上，我們不是在同一個(gè)系統(tǒng)上同時(shí)處理兩個(gè)編碼，每個(gè)編碼在一個(gè)小時(shí)內(nèi)生成5分鐘的編碼片段，而是在處理一個(gè)編碼，它的運(yùn)行速度是這個(gè)編碼的兩倍，每小時(shí)生成10分鐘的編碼片段。在這兩種情況下，總體系統(tǒng)吞吐量都是每小時(shí)10分鐘，但是多線程編碼的工作速度是前者的兩倍。如果您正在創(chuàng)建一個(gè)并行處理多個(gè)編碼的編碼器，則可能不希望使用這些設(shè)置。如果您在系統(tǒng)上運(yùn)行一個(gè)FFmpeg實(shí)例，那么你幾乎肯定會(huì)這樣做。

所以，讀者現(xiàn)在或許會(huì)理解我開(kāi)始說(shuō)我不是在比較兩者間的差別，而且我對(duì)其他編解碼器也不公平。x264，x265和LibVPx都有自己的質(zhì)量/速度曲線，如果我們要對(duì)AV1應(yīng)用“實(shí)用”設(shè)置，我們應(yīng)該對(duì)這三個(gè)編解碼器做同樣的設(shè)置。

具體地說(shuō)，如果對(duì)LibVPx使用speed 2(而不是最高質(zhì)量的speed 0)，對(duì)x264和x265使用slow預(yù)置(而不是非常慢)，我們將得到如表6所示的時(shí)間。這使得AV1的制作成本幾乎是x265和LibVPx的20倍，這只適用于編碼高6位數(shù)和7位數(shù)的觀眾數(shù)量。到目前為止，使用新編解碼器制作視頻的通常是Netflix、Facebook和YouTube等公司(以及AOM聯(lián)盟成員)。令人印象深刻的速度增長(zhǎng)我相信還會(huì)有更多。

我在表6中展示的VMAF分?jǐn)?shù)僅供參考;單個(gè)5秒1080p編碼比編碼的3 Mbps容易，剪輯不足以得出任何與質(zhì)量相關(guān)的結(jié)論。相反，您需要查看來(lái)自多個(gè)剪輯的速率失真曲線和BD速率比較。我會(huì)在接下來(lái)的幾周內(nèi)更新AV1審核的結(jié)果，以創(chuàng)建相關(guān)的比較數(shù)據(jù)。

表6. 使用最“實(shí)用”的設(shè)置進(jìn)行速度比較。

在此期間，如果您正在編碼AV1，請(qǐng)嘗試使用不同的cpu使用設(shè)置以及tile和線程，并查看結(jié)果是否相似。如果您閱讀任何參考編碼時(shí)間的AV1比較評(píng)論，請(qǐng)檢查并查看研究人員使用的cpu使用設(shè)置。如果未指定，則默認(rèn)值為1，這可能是真正的生產(chǎn)者不會(huì)使用的設(shè)置。如果它是cpu-used 0，雖然可以說(shuō)適用于學(xué)術(shù)研究，編碼時(shí)間與真正的生產(chǎn)者實(shí)際使用編解碼器的方式完全沒(méi)有關(guān)系。

為了幫助那些想要嘗試這些新設(shè)置的人，這里是FFmpeg命令字符串的最終版本。