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进行更优化）。