Are there plans to add support for screen sharing audio in the Web SDK? This is so that if someone plays a video while screen sharing, it also sends the audio. Apparently I’m hearing that right now the audio isn’t broadcast.
Are there any guidelines regarding screen sharing framerate? I’m getting reports that videos played during screen sharing are only about 1 or 2 frames per second. Is this dependent on the hardware of the person sharing? My customers are asking me why the native app is so smooth when the Web SDK isn’t, and the best answer I have so far is because it’s being constrained by running in a web page and probably doesn’t have the same level of access to the hardware resources that a native app would. Is there a better answer, or a set of minimum or recommended specifications?
Are there plans to allow the gallery view to show more than 9 people at once?
Thank you for reaching out to the Zoom Developer Forum. I’m happy to help out here!
Yes, based on a previous communication with our engineering team, this is something that we plan to add in a future release but we don’t have a timeline for it just yet.
If you’re seeing performance issues with the Web SDK, you may want to try enabling the WebAssembly SIMD Origin Trial that is mentioned here.
More information can be found in the Chrome Origin Trials documentation as well as this dev forum post:
You can also find an example of how to test for SIMD support in our Sample Web App:
Yes, the framerate of a shared screen has to do with multiple factors relating to the user screen sharing as well as the recipient user. Quality and framerate can depend on the compute and network resources available to both parties.
While Zoom does its best in the background to prioritize clear communication and a smooth connection sometimes the resources are too limited.
You’re correct in that most of the performance difference between the Zoom App and the Web SDK is that the Zoom App is able to use native code in order to achieve the same functionality. Often, browser APIs are high level which means there is likely a performance impact.
Another piece of the puzzle is the APIs that browsers make available. As browsers release lower level APIs that we can use, we’ll be able to write code in the browser that performs closer to native code. It will also allow us to support a wider featureset across supported browsers and improve performance.
Something else to look out for is other threads, processes or functionality running on the page. If your app has functionality outside of the Web SDK that impacts compute or network resources, that could factor into the performance of the Web SDK as well.
Of course, we are always working on our end to make sure that the Web SDK performs as efficiently as possible.
I don’t have any confirmation on this but we are always working to reduce the feature gap between web and native platforms. You can keep up to date with the latest features and fixes with our changelog and at developers.zoom.us.
I hope that helps! Let me know if you have any questions.