The text/GUSTAVO GARCIA

The original link/www.rtcbits.com/2021/02/web…

In WebRTC, the best and most popular codecs are VP8 and H.264, but these are not our only choices. VP9 has been available for some time, and some large services are using it, such as Chrome, which recently added support for AV1.

There are some interesting factors to consider when comparing codecs, such as interoperability and licensing, but perhaps the most important are how well codecs perform in terms of compression and how cheap codecs are in terms of CPU and memory usage.

Compression rates are usually the first thing to consider, and there are many comparisons that can be made for this, but resource consumption is just as important if we want to be able to use codecs for real-time use cases.

Since AV1 is available in the Chrome Canary version, I decided to run some tests to evaluate the CPU usage of the four codecs available in the WebRTC ecosystem. The purpose of this test is to compare the entire video pipeline to the four codecs, not just the codecs individually.

The test environment

These tests are done using a simple web page that establishes a connection between two PeerConnections (one sends and the other receives). If you want to run the tests yourself, see the tests page:

jsfiddle.net/tvo7czxs/

The tests using this page changed three variables:

  • Codec: VP8, VP9, H264, AV1

  • Resolution: HD, VGA, QVGA

  • Bit rate: 200Kbps, 800Kbps, 2Mbps

If you look at the test page, you can easily change these three parameters to run the tests in other configurations or on other devices.

The Chrome version used is the latest version (1/2/21) synchronized from Git this week, tested on a MacBook Pro (2.4ghz 8-core Intel Core I9).

To check CPU usage, I waited 30 seconds and then looked at the average CPU consumed by Chrome processes in the System activity monitor to give time for bandwidth estimation and resolution/frame rate adaptive stabilization within WebRTC. When the result below is 100%, it means that the machine has 1 complete core.

Nothing fancy, but hopefully this is easy enough for you to understand.

In that environment, I ran the 36-parameter combination several times, averaged the results and summarized them in the following sections:

QVGA test results

The results are as expected in terms of QVGA resolution, where VP9 requires more CPU than VP8 and AV1 requires almost twice as much CPU. H.264 is one that requires less CPU usage because it uses hardware acceleration for this purpose.

VGA Test results

For VGA, the results were not very different, but only VP9 maintained resolution at low bitrate, while AV1 used more than one kernel when the bitrate limit was raised to 2 Mbps. The quality of H.264 at 200Kbps is really poor and the frame rate is low and the blocking is obvious, since Chrome’s adaptability obviously doesn’t work very well in this case.

HD (1280×720) test results

HD results were similar to VGA results, but AV1 was unable to encode the original resolution and narrowed it down for all bitrate tests. H.264 also performed poorly at low bit rates, and the cost difference between VP8 and VP9 was much higher than VGA.

(Also, AV1 in HD resolution often crashes due to memory issues with Mac-related code, but this bug may have been fixed by the time you read this article)

Encoding VS decoding costs

I ran another test to divide the cost between encoding (sender) and decoding (receiver). This test was done with VGA at 800 Kbps, and the test results are the results of the next four codecs under consideration.

There was little difference, but decoding of VP9 and AV1X was relatively inexpensive compared to encoding.

Just comparing decoding costs to different codecs, it looks like AV1 is about 2x more expensive than other codecs. VP9 costs slightly more than VP8, and VP8 costs slightly more than H.264, but there’s not much difference between the three.

conclusion

The new codec is a pleasant surprise and there is no doubt that AV1 is the future of real-time video communication, but it looks like we should be patient with it for some time before we can use it in general purpose video conferencing applications. At the same time, we may also use it for specific use situations such as broadcasting, dedicated powerful devices, or encoding a lower-resolution version of a video stream when using simulcast.

For other use cases, VP8 and VP9 still look like the best choices, unless you’re not too worried about low bit rates, or you’re using high resolution and battery/CPU consumption is a big issue, but you can consider H.264.

In addition, it is clear that a new Libaom patch is on the way to improve performance by 15%, so it would be good to repeat these tests in future versions of Chrome and on different devices (AV1 may be more optimized for ARM CPUs).