[sam_goody]

As much as I love FF, this is not true. Chrome supports VP9, FF/Safari do not. VP9 is a huge leap ahead of VP8, and Google is not wrong to use it in Meet. What's more, FF only supports UDP which requires a much less firewalled environment.

On another note, the lack of support for sessions is the real killer for me. And the lack of WebSocket debugging is a big strike against the dev in me. I use FF as my primary browser, but gotta give credit where it is due.

[ac29]

FF definitely supports VP9 (at least on Linux). Easy to check by loading up a YouTube video and right clicking to get the "Stats for nerds".

[sam_goody]

It supports VP9, but not in WebRTC. Or at least, not without enabling a flag on each viewers computer[0]. I am running Nightly, and can verify that it is _still_ behind a flag.

I suspect they don't realize how many viewers this costs them, as this has been behind a flag for months already, meanwhile RTC users are being told "We recommend Chrome".

[0] https://stackoverflow.com/a/38701342/87520

[acdha]

Google should support H.264 as well. The quality is close to VP9 (i.e. most users won’t notice a difference) and the hardware acceleration makes a huge difference on all but the latest systems. Saving a little bandwidth at the expense of going from 10% to 100+% CPU is a net loss, especially for battery powered devices.

[vetinari]

Systems from last few years have VP9 encoding too, only AMD is a laggard in this regard (Raven Ridge is the first GPU to support it).

And while we are talking about hardware, it would be nice, if both Chrome and Firefox supported hw accelerated decoding on Linux. Currently, they don't support it at all.

[acdha]

Yes, it’s appearing but it’s not anywhere near a given, especially on corporate and non-gamer systems — exactly the majority of users who don’t care about bandwidth if it means their CPU fans are on high driving a slideshow.