I tried using the Zoom webapp on Firefox, on X11, for quite a while, but eventually I gave up and started using the native app. The web app is slow and burns CPU (and my laptop fans start going nuts), and for some reason the quality of the video that's coming out of my camera looks much worse on the webapp. (This isn't the case for Google Meet on Firefox, so it's something about Zoom's webapp.)
If I were to switch to Wayland and have to go back to the webapp for Zoom, that would be annoying.
(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
I've been screensharing using the Zoom web application (via Firefox) on Wayland for almost 5 years now, and it's always worked well for me personally.
Does screen annotation work on it? It's loss in the wayland version of zoom has been a major pain for me at work.
Not annotating when you yourself are screen sharing, but when someone else is screen sharing you can draw on their screen(aka annotating)?
Sorry, but I've never tried that before, so I'm not sure. (I didn't even know that Zoom had that feature at all!)
I tried using the Zoom webapp on Firefox, on X11, for quite a while, but eventually I gave up and started using the native app. The web app is slow and burns CPU (and my laptop fans start going nuts), and for some reason the quality of the video that's coming out of my camera looks much worse on the webapp. (This isn't the case for Google Meet on Firefox, so it's something about Zoom's webapp.)
If I were to switch to Wayland and have to go back to the webapp for Zoom, that would be annoying.
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.