Chrome 89 Preparing To Ship With AV1 Encoder For WebRTC Usage

[phoronix]

Phoronix: Chrome 89 Preparing To Ship With AV1 Encoder For WebRTC Usage

Now that Chrome 88 released, attention is turning to Chrome 89 of which an interesting technical change is the enabling of AV1 encode support within the web browser...

http://www.phoronix.com/scan.php?page=news_item&px=Chrome-89-AV1-Encoding

[FireBurn]

Considering the number of devices with native hardware h264 encode and decode, it seems a bit strange to be moving to av1, which will use more power, or is this just adding the option for when av1 becomes more widely available

[nazar-pc]

Considering the number of devices with native hardware h264 encode and decode, it seems a bit strange to be moving to av1, which will use more power, or is this just adding the option for when av1 becomes more widely available

As someone who works with WebRTC I can assure you that not every hardware acceleration is suitable, is used or doesn't cause various issues including browser crashes.
It is nice when it works, but most often it doesn't for WebRTC.

[M@GOid]

Considering the number of devices with native hardware h264 encode and decode, it seems a bit strange to be moving to av1, which will use more power, or is this just adding the option for when av1 becomes more widely available

They are not moving to AV1, just enabling it. The other codecs will remain available.

[Artim]

Considering the number of devices with native hardware h264 encode and decode, it seems a bit strange to be moving to av1, which will use more power, or is this just adding the option for when av1 becomes more widely available

WebRTC applications can set a preference. e.g. Jitsi Admins can set either VP8 or h.264 as preferred codec. Of course the one that can be used best with every participant will be used

As someone who works with WebRTC I can assure you that not every hardware acceleration is suitable, is used or doesn't cause various issues including browser crashes.
It is nice when it works, but most often it doesn't for WebRTC.

While that might be true, h.264 undoubtedly should be much faster either way since it's much easier to encode

[nazar-pc]

While that might be true, h.264 undoubtedly should be much faster either way since it's much easier to encode

Encoding is not always the most intensive operation in multi-party WebRTC communication
And for some AV1 with half bitrate may be very well worth extra CPU cost, so it is great that there is now this option.

[darkbasic]

Encoding is not always the most intensive operation in multi-party WebRTC communication
And for some AV1 with half bitrate may be very well worth extra CPU cost, so it is great that there is now this option.

What should be the most intensive one then? Decoding because of the multiple streams?

[nazar-pc]

What should be the most intensive one then? Decoding because of the multiple streams?

Often yes, and VPx are sometimes faster to decode. Also rendering depending on how optimized it is (there was a lot of tuning in Chromium related to this recently).

[Artim]

Encoding is not always the most intensive operation in multi-party WebRTC communication
And for some AV1 with half bitrate may be very well worth extra CPU cost, so it is great that there is now this option.

well, I can tell you from experience that it's true at least for older hardware. On my Laptop with a Core i5-4210U there is no way I can use Jitsi in Chrome when using VP8, I would have to resort to my phone. Otherwise, both my audio and video quality is horrible and the video quality of others is very bad. No problem when forcing it to h.264. Or when using Zoom, which for all I know uses h.264...as long as you don't use the browser version (at least it was unusable for me about a year ago).

But I can't tell you if there were any improvements in the last half year, the compatibility of Jitsi is just too bad, so we currently use Zoom for everything.

[skeevy420]

Encoding is not always the most intensive operation in multi-party WebRTC communication
And for some AV1 with half bitrate may be very well worth extra CPU cost, so it is great that there is now this option.

Exactly. Wall plugs are everywhere and ISP bandwidth quotas are usually ridiculously expensive.