The work to add RTC AV1 in Chrome, which started in November last year is now well underway. Many people still ask the legitimate question: when will it be available and how good will it be. We had planned to deliver the implementation at IETF in Vancouver at the end of the month and make demos, but the IETF like many other events has been cancelled, so we are switching to weekly updates until the release, still planned for April. This post provides some information about both timing and quality questions.

Many have noted that in the Announcement of Chrome 80 availability, mention of AV1 support was added. It was a reference of the implementation of the AV1 RTP payload support, with corresponding SDP signalling.

Having support for RTP is always the first step when adding a codec in libwebrtc, but without a proper encoder and decoder implementation, it is unusable.

libaom, which implements the reference encoder and decoder for AV1, has been included in chromium, and by extend libwebrtc, for a few years already. Originally only the decoder part was added to the chromium code base, and it was only used in the traditional media pipeline to allow e.g. YouTube or Netflix to stream AV1 content to chrome and that content to be displayed in a <video> HTML5 element.

More recently the AV1 encoder part of libaom has also been added, behind a compilation flag, to start enabling AV1 in libwebrtc, while shielding chrome builds from it. The final pieces to this should be added to the code source this week, by the webm / libaom team.

Once you have an encoder/decoder available, and RTP support for the same codec available, you need to add a little bit of glue code in the form of a webrtc’s VideoEncoderFactory. This class takes as input the codec description from the SDP, and return, if available, an Encoder, respectively Decoder, which can provide implementation of the codec, including options like profile, level, sampling, … requested. The webrtc team in stockholm already provided the corresponding code for the decoder publicly (here), and the code for the encoder will follow in a week or two.

At that stage, AV1 in webrtc will be usable. It will require compiling from source, but most webrtc vendors have this capacity. If not, you can always contact us. However, it will only support single layer AV1, e.g. it will not support SVC. It is expected that adding support for SVC will take another couple of weeks, at which point CoSMo will also deliver an open source SFU implementation, and KITE tests for anybody to (blatantly poach, copy and plagiarise without giving any credit) … inspire themselves from, and benchmark with.

Benchmarking will be a very important part.

Speed. The setting of libaom for webrtc shall be “speed 8”. Each speed level runs 2 times faster than the previous one, and speed 8 is what is considered real-time, and used e.g. with VP8 and VP9 in libvpx when used in libwebrtc. How does that translate on specific hardware can only really be answer through benchmarking.

Quality. At first, only 8bits color depth, and 4:2:0 chroma sampling will be supported (just like Vp8 and VP9 right now), which correspond to a subset of AV1 mode 1. The possible extension to 10, 12bits, and 4:2:2 or 4:4:4 (think “HDR”) is under discussion but will not happen in this phase. Note that 4:4:4 format is supported in libwebrtc, and, separately, VP9 mode 2 (4:2:0, 10bits) is also supported today.

Compression gain. For now, libaom AV1 speed 8 seems to provide an average of 10% compression improvement over libvpx VP9 speed 8. The AV1 code base is being optimised as we speak (replacing most low level functions by assembly code), and 2.5x improvement quarter over quarter are not unheard of.

CoSMo is also planning to provide separately several VideoEncoderFactory wrapping other encoder / decoder than libaom for fair comparison. Is Dav1d really that good (for both encoding and decoding)? Is NETFLIX / INTEL SVT-AV1 really real-time like they claimed at NAB 2019, or at best live (3+s)? What are the respective CPU footprint in RTC use cases …

Don’t trust us, don’t trust them, test yourself.