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

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

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

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

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

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

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

編碼器速度的提升

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

如果對當(dāng)前版本的FFmpeg使用相同的字符串(我測試了N-93083-g8522d219ce版本)，編碼時間從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的改進）

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

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

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

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

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

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

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

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

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

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

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

運行多個線程

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

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

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

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

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

表5.在其他測試編碼中部署多個線程

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

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

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

雖然這些設(shè)置不會增加任何特定編碼運行的編碼速度，但它們可能不會增加任何給定系統(tǒng)上的編碼吞吐量。這是因為它們似乎并沒有提高編碼效率，就其本身而言，它們似乎允許每個單獨的編碼消耗更多的CPU資源，這在任何給定的系統(tǒng)上都是一個零和數(shù)字。

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

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

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

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

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

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

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