3 ms·

a few comments from somebody who worked for many years for a competitor to Zoom. The article author complains about some relatively minor details but completel

a few comments from somebody who worked for many years for a competitor to Zoom. The article author complains about some relatively minor details but completely misses the big picture. I'm not going to talk about the availability and quality of the Wayland API, this was covered in other posts. Here is what the decision looks like from the POV of someone building a product: - Zoom is one of the few collaboration products which supports Linux with a native client. The native clients offer much better performance on every operating system. - Some of the collaboration products (Zoom being one of them) implement 2 different codecs for the video streams and screen sharing. This is done to offer better performance, lower bandwidth, and better quality. For screen sharing the most important requirement is not which API is used, but if the text is readable. - Zoom is a multiplatform product. All other platforms offer API for screenshots. Not all platforms have an API that captures the screen as a video stream. Using screenshots is the best way to cover all platforms. - Collaboration products have high requirements for screen sharing: Capturing the entire desktop, capturing a single application, capturing a portion of the screen, excluding its own UI, etc. Support for multiple monitors, 4k, 5k support. Most of these use cases are not going to be covered by the Wayland API. - This is a different use case than streaming your screen to twitch or youtube. Collaboration products have very low latency ( < 500ms). The presenter can change and any moment and clients can join at any time and they expect the screen-sharing stream to start immediately. - Zoom supports h264 as their main codec. API which provides VP8 will require contradicting and encoding which will slow down the performance. - Even if the video stream coming directly from the screen didn't require transcoding, it is still required to do a post processing. For screen sharing (with no video on the screen) it is wasteful to generate too many frames.

throwdbaaway 5y ago
> The native clients offer much better performance on every operating system. Background blur uses significantly less CPU in Google Meet running as a chrome/chromium tab, than in native Zoom Linux client. Besides, Zoom Linux client also makes some arbitrary decision that my more powerful i7-3720QM is not qualified to have background blur enabled, while my less powerful i5-8250U is allowed to do so. Background blur works just fine with both CPUs in Google Meet. From your POV, perhaps Zoom product/engineering is doing a good enough job. From my POV, what we have is a crappy Zoom Linux client and a half-arsed Zoom web client. And if corporate wants to give everyone Mac and Windows machines only, just so its highly paid engineers and highly paid product managers can share their screen over a Zoom session, who can argue with that logic?
- avrionov 5y ago
  My comments are directed at the general performance of Video and Audio components. Zoom implements their own protocol which performs better than the WebRTC. Their codecs are also better optimized, on of the reasons being that VP8 lacks hardware optimization on many platforms. Background blur most likely require GPU optimization. The implementation on Windows/Mac and Linux looked different for a while. It is possible that they had to deal with compatibility and driver issues on Linux.
hkmaxpro 5y ago
I really appreciate your explanation from the point of view of the software developer. One question: Zoom web client supports screen sharing using WebRTC Screen Capture API. This is why Zoom web client allows screen sharing using pipewire on Wayland. Do you think WebRTC screen sharing codec offers suboptimal performance?
- avrionov 5y ago
  I don't work for Zoom, so this will be my best guess. WebRTC supports VP8 and h264, but it really depends on the platform. h264 is not free and may not be available. The screen capture API will give them a video stream which they need to decode and the encode again in their own format. This is where some of the efficiencies will come. It is also more likely that h264 to be hardware optimized than vp8.

throwdbaaway 5y ago

> The native clients offer much better performance on every operating system. Background blur uses significantly less CPU in Google Meet running as a chrome/chromium tab, than in native Zoom Linux client. Besides, Zoom Linux client also makes some arbitrary decision that my more powerful i7-3720QM is not qualified to have background blur enabled, while my less powerful i5-8250U is allowed to do so. Background blur works just fine with both CPUs in Google Meet. From your POV, perhaps Zoom product/engineering is doing a good enough job. From my POV, what we have is a crappy Zoom Linux client and a half-arsed Zoom web client. And if corporate wants to give everyone Mac and Windows machines only, just so its highly paid engineers and highly paid product managers can share their screen over a Zoom session, who can argue with that logic?

avrionov 5y ago
My comments are directed at the general performance of Video and Audio components. Zoom implements their own protocol which performs better than the WebRTC. Their codecs are also better optimized, on of the reasons being that VP8 lacks hardware optimization on many platforms. Background blur most likely require GPU optimization. The implementation on Windows/Mac and Linux looked different for a while. It is possible that they had to deal with compatibility and driver issues on Linux.

hkmaxpro 5y ago

I really appreciate your explanation from the point of view of the software developer. One question: Zoom web client supports screen sharing using WebRTC Screen Capture API. This is why Zoom web client allows screen sharing using pipewire on Wayland. Do you think WebRTC screen sharing codec offers suboptimal performance?

avrionov 5y ago
I don't work for Zoom, so this will be my best guess. WebRTC supports VP8 and h264, but it really depends on the platform. h264 is not free and may not be available. The screen capture API will give them a video stream which they need to decode and the encode again in their own format. This is where some of the efficiencies will come. It is also more likely that h264 to be hardware optimized than vp8.