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.
Not annotating when you yourself are screen sharing, but when someone else is screen sharing you can draw on their screen(aka annotating)?
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:
media.ffmpeg.disable-software-fallback=true
media.ffmpeg.vaapi.enabled=true
media.gmp.decoder.enabled=false
media.gpu-process-decoder=true
media.gpu-process-encoder=true
media.hardware-video-decoding.force-enabled=true
media.hardware-video-encoding.force-enabled=true
media.webrtc.hw.h264.enabled=true
media.webrtc.software_encoder.fallback=false
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.
They're a mess everywhere for legal reasons. The solution is what Chrome and many other apps do: just ship codecs with the app.
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.
Not if you install Chrome, Brave, Vivaldi, etc... like most users...
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...
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.