(I'm not sure if all of those are necessary, but that's what I'm currently using.)
Then in Linux, make sure that you have the full versions of all the codecs installed; in Fedora, you need to install "mesa-va-drivers-freeworld" and "ffmpeg" from rpmfusion (and uninstall "mesa-va-drivers" and "ffmpeg-free" from the regular repos); for other distros, the steps should be similar.
But after all that, my Firefox uses only 20% of a single CPU to run Zoom, so my laptop is cool and the fan stays off.
(I agree that it's really annoying that all of these steps are needed just to make video work well, but they're orthogonal to Wayland, and would be needed with X11 in the browser too.)
This isn't the case for Google Meet on Firefox, so it's something about Zoom's webapp.
Google Meet probably uses VP9 or AV1 (since both are developed by Google), and those are both patent-free so should have no issues on Linux. Whereas Microsoft Teams and Zoom only use h264, which for patent reasons is limited to software-only by default [0]. I'm guessing that Zoom Linux application likely embeds the relevant codecs, which would be why it works there without any extra steps.
Sure, I understand why most Linux distros omit proprietary codecs (and mostly agree with it). But to the average user, it's not easy to explain why h264 videos play out-of-the-box on Windows and macOS, while you need to first run some arcane terminal commands on Linux. And hardware decoding is even more confusing, because you would assume that the hardware manufacturer would have already paid any necessary royalties, but of course things can't be so simple [0].
But AV1 is starting to become fairly popular, and most of the h264 patents have expired, so this should all hopefully be a non-issue in a few years.
1. Most Linux distros install Firefox by default while very few install Chromium, so I suspect that most Linux users use Firefox (even though Chrome is far more popular in general).
2. On Fedora, openSUSE, and similar distros, the Mesa in the main repos is built without h264 hardware decoding support, so no applications will be able to use hardware decoding unless you run some terminal commands. That being said, the more user-friendly distros tend to have this enabled by default.
3. Chromium doesn't officially support hardware decoding on Linux at all [0], whereas Firefox does. (Hardware decoding still works, it's just not officially supported.)
4. Up until a few months ago [1], you had to start Chromium with some special flags [2] to enable hardware decoding.
5. Hardware decoding should be enabled in Firefox by default, so those "about:config" flags for Firefox that I mentioned above shouldn't be necessary in most cases, but since it wasn't working for the OP, I suggested those flags to force-enable it. (A few years ago, hardware decoding would crash occasionally, and Firefox automatically disables it if it has ever crashed in the past before. It's super stable now, but old installations will often have it disabled due to bugs that were fixed years ago.)
Sorry, my earlier posts were all talking about hardware decoding, so I had assumed that it was implied that I was talking about hardware decoding in this reply too. But I see that I never actually mentioned that anywhere, so my bad.
Comments
Ah yeah, that's because codecs are (still) a mess on Linux. In Firefox, navigate to about:config, then make sure that the following are set:
(I'm not sure if all of those are necessary, but that's what I'm currently using.)Then in Linux, make sure that you have the full versions of all the codecs installed; in Fedora, you need to install "mesa-va-drivers-freeworld" and "ffmpeg" from rpmfusion (and uninstall "mesa-va-drivers" and "ffmpeg-free" from the regular repos); for other distros, the steps should be similar.
But after all that, my Firefox uses only 20% of a single CPU to run Zoom, so my laptop is cool and the fan stays off.
(I agree that it's really annoying that all of these steps are needed just to make video work well, but they're orthogonal to Wayland, and would be needed with X11 in the browser too.)
Google Meet probably uses VP9 or AV1 (since both are developed by Google), and those are both patent-free so should have no issues on Linux. Whereas Microsoft Teams and Zoom only use h264, which for patent reasons is limited to software-only by default [0]. I'm guessing that Zoom Linux application likely embeds the relevant codecs, which would be why it works there without any extra steps.
[0]: https://en.wikipedia.org/wiki/OpenH264
They're a mess everywhere for legal reasons. The solution is what Chrome and many other apps do: just ship codecs with the app.
Sure, I understand why most Linux distros omit proprietary codecs (and mostly agree with it). But to the average user, it's not easy to explain why h264 videos play out-of-the-box on Windows and macOS, while you need to first run some arcane terminal commands on Linux. And hardware decoding is even more confusing, because you would assume that the hardware manufacturer would have already paid any necessary royalties, but of course things can't be so simple [0].
But AV1 is starting to become fairly popular, and most of the h264 patents have expired, so this should all hopefully be a non-issue in a few years.
[0]: https://lwn.net/Articles/910978/
Not if you install Chrome, Brave, Vivaldi, etc... like most users...
1. Most Linux distros install Firefox by default while very few install Chromium, so I suspect that most Linux users use Firefox (even though Chrome is far more popular in general).
2. On Fedora, openSUSE, and similar distros, the Mesa in the main repos is built without h264 hardware decoding support, so no applications will be able to use hardware decoding unless you run some terminal commands. That being said, the more user-friendly distros tend to have this enabled by default.
3. Chromium doesn't officially support hardware decoding on Linux at all [0], whereas Firefox does. (Hardware decoding still works, it's just not officially supported.)
4. Up until a few months ago [1], you had to start Chromium with some special flags [2] to enable hardware decoding.
5. Hardware decoding should be enabled in Firefox by default, so those "about:config" flags for Firefox that I mentioned above shouldn't be necessary in most cases, but since it wasn't working for the OP, I suggested those flags to force-enable it. (A few years ago, hardware decoding would crash occasionally, and Firefox automatically disables it if it has ever crashed in the past before. It's super stable now, but old installations will often have it disabled due to bugs that were fixed years ago.)
[0]: https://chromium.googlesource.com/chromium/src/+/master/docs...
[1]: https://issues.chromium.org/issues/40225939#comment67
[2]: https://wiki.archlinux.org/title/Chromium#Hardware_video_acc...
So moving goalposts... Normies don't care about hardware decoding, they care that the thing plays.
Also Windows doesn't have 100% codec coverage either: https://learn.microsoft.com/en-us/windows/apps/develop/media...
Hence Chrome and others shipping codecs...
Sorry, my earlier posts were all talking about hardware decoding, so I had assumed that it was implied that I was talking about hardware decoding in this reply too. But I see that I never actually mentioned that anywhere, so my bad.