GUSTAVO GARCIA在同一測試環境下，測試得出不同編碼器的CPU使用結果。

在WebRTC中，公認為優秀的和最受歡迎的編解碼器是VP8和H.264，但這兩個編解碼器并不是我們唯一的選擇。VP9已經可用了一段時間，并且一些大型的也服務正在使用它，例如最近Chrome就增加了對于AV1支持。

在比較編解碼器時，需要考慮一些有趣的因素，例如互操作性和許可，但最重要的因素可能是編解碼器在壓縮方面的性能如何，以及編解碼器在cpu和內存使用方面的便宜程度。

壓縮率通常是我們首先要考慮的事情，并且存在著許多可用于此的比較，但是如果我們希望能夠將編解碼器用于實時用例，則資源消耗同樣重要。

鑒于AV1在Chrome Canary版本中可用，我決定運行一些測試來評估WebRTC生態系統中4種可用編解碼器的CPU使用情況。該測試的目的是將整個視頻管道與這4個編解碼器進行比較，而不僅僅是單獨比較編解碼器。

測試環境

這些測試是通過一個簡單的網頁完成的，該網頁在2個PeerConnections之間建立了連接（一個發送和另一個接收）。如果您想自己運行測試，請參見測試頁面：

https://jsfiddle.net/tvo7czxs/

使用該頁面進行的測試改變了3個變量：

編解碼器：VP8、VP9、H264、AV1

分辨率：高清、VGA、QVGA

比特率：200Kbps、800Kbps、2Mbps

如果您查看測試頁面，很容易就可以更改這3個參數，以便在其他配置或其他設備中運行測試。

使用的Chrome版本是本周從git同步的最新版本（1/2/21），測試在MacBook Pro（2.4 GHz 8核 Intel Core i9）中進行。

為了檢查CPU的使用率，我在等待30秒后，就在系統活動監視器中查看了Chrome進程平均消耗的CPU，以便為WebRTC內帶寬估計和分辨率/幀速率自適應的穩定提供時間。當下面的結果是100％時，表示該機器有1個完整核。

沒什么花哨的，但希望這可以足夠容易使大家理解。

在那種環境中，我運行了幾次36個參數組合，將結果取平均值，并在以下各節中進行了總結：

QVGA測試結果

對于QVGA分辨率這一方面來說，結果是符合預期的，其中VP9比VP8需要更多的CPU，而AV1則需要的CPU幾乎是VP8的2倍。H.264是一種需要較少的CPU使用量，因為它為此使用了硬件加速。

% of CPU usage with different codecs

QVGA200kbps800kbps2Mbps

VP8182228

VP9202833

H.264101415

AV1364650

VGA測試結果

對于VGA，結果并沒有很大差異，但是在低比特率時，只有VP9才能保持分辨率，而當將比特率限制提高到2 Mbps時，AV1使用了1個以上的內核。H.264在200Kbps時的質量真的很差，而且幀速率很低，阻塞也很明顯，由于在這種情況下，Chrome瀏覽器的適應性顯然不能非常好的工作。

HD（1280x720）測試結果

HD的結果與VGA的結果相似，但AV1無法對原始分辨率進行編碼，在所有比特率的測試中縮小了分辨率。H.264在低比特率下的表現也很不盡人意，并且VP8和VP9成本之間的差異比VGA高得多。

（另外，高清分辨率的AV1經常會因為Mac相關代碼的內存問題而崩潰，但也許這個bug在你讀這篇文章的時候已經修復了）

編碼 VS 解碼成本

我又進行了一次測試，以在編碼（發送方）和解碼（接收方）之間劃分成本。該測試是針對VGA以800 Kbps進行的，而測試結果正是下一個正在考慮的四個編解碼器的結果。

結果差別不大，但與編碼相比，VP9和AV1X的解碼相對便宜。

僅將解碼成本與不同的編解碼器進行比較，看起來AV1的價格要比其他解碼器貴2倍左右。VP9的價格比VP8的價格稍高，而VP8的價格比H.264的價格略高，但三者之間沒有太大差異。

總結

有了新的編解碼器是令人驚喜的，毫無疑問，AV1是實時視頻通信的未來，但它看起來我們應該耐心等待一些時間，以便日后能夠將其用于通用視頻會議應用程序之中。與此同時，我們可能還會將它用于特定使用情況，如廣播，專用的功能強大的設備，或在使用聯播時對視頻流的低分辨率版本進行編碼。

對于其他用例，VP8和VP9看起來仍然是最好的選擇，除非您不太擔心低比特率的情況，或者您正在使用高分辨率，并且電池/cpu消耗是一個大問題，不過您可以考慮H.264。

另外，很明顯，新的libaom補丁即將面世，可以將性能提高15%，因此在Chrome的未來版本和不同的設備上重復這些測試是很好的（AV1可能會對ARM CPUs進行更優化）。
編輯：lyn