WebRTC視頻編解碼器性能評估

文 / GUSTAVO GARCIA

原文連接 /
http://www.rtcbits.com/2021/0...

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

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

壓縮率一般是咱們首先要考慮的事情，而且存在着許多可用於此的比較，可是若是咱們但願可以將編解碼器用於實時用例，則資源消耗一樣重要。

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

測試環境

這些測試是經過一個簡單的網頁完成的，該網頁在2個PeerConnections之間創建了鏈接（一個發送和另外一個接收）。若是您想本身運行測試，請參見測試頁面：

https://jsfiddle.net/tvo7czxs/

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

• 編解碼器：VP八、VP九、H26四、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使用量，由於它爲此使用了硬件加速。

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進行更優化）。