AV1最初發布時，編碼速度緩慢，時間過長，嚴重影響編碼器的可用性。隨著不斷的優化，其編碼時間已經有很大改進，幾乎可以使用。

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

表1. AV1首次發布時的編碼時間

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

表2. AV1當前的優化編碼時間

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

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

編碼器速度的提升

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

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

表3.使用帶有當前代碼的原始命令行（AOM的改進）

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

尋找AV1的最佳速度/質量權衡

大多數編解碼器都有預設，可以讓你權衡編碼時間的質量。例如，對于x264和x265，預設的名稱包括慢速、非常慢、快速、非常快和中等。使用AV1，預設通過cpu-usedswitch控制，你可以在上面的批次中看到我使用cpu-used8in pass 1和cpu-used0in pass 2。

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

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

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

圖1. AV1的質量/速度曲線

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

表4. 當前版本的FFmpeg、cpu-used 5

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

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

運行多個線程

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

如果在運行編碼器時可以使用多個線程，則有助于編碼器速度。對于高清及以上分辨率，我們建議使用區塊（tile）。使用區塊會導致質量下降，我的舊測試顯示，使用2個區塊時損失約0.6％，使用4個區塊時損失約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“）”

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

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

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

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

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

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

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

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

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

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

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

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

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