We have 30 weekly participants on our video chat and for 26 of them there is no issue using our implementation of VideoSDK. However, for 4 customer, (all using older macbook laptops + Chrome browser) they are unable to render self-view and view others videos.
Their camera/video stream turns on and others on the call are able to see their video, however they are not able to see their own self-view, or anyone else on the call (except 1 participant).
Can you please share the code behind isSupportMultipleVideos() ? I have remote logging set up and each of these customers’ browsers does correctly support Shared Array Buffer, it is enabled.
Our same code works as expected (gallery view, self-view) every week for the other 26 people. Trying to root cause this issue.
We analyzed the session and found that the problematic user was running the page on a low-performance device, likely a MacBook with a Core i5 5250U. To support rendering multiple videos, a 4-core CPU is required, which we detect using the navigator.hardwareConcurrency method.
Additionally, I saw in the screenshot, the user was using Brave browser, which has a known limitation: the navigator.hardwareConcurrency result can be inaccurate.
To handle cases where stream.isSupportMultipleVideos() returns false, it is recommended to display only a fixed video view or the active speaker view for this user. We also provide corresponding events to assist in implementing this function.
Thanks Vic! this is really helpful information. Is there any way to get/force gallery view on a device like this?
We typically only have 2-5 people on the calls at a time, and single view/active speaker is just not the group video experience we’re trying to build. For the type of calls we run, it is important that everyone is visible.
And I’m pretty certain this used to work? We started running into this issue when we updated from
“@zoom/videosdk”: “^1.6.0”,
Also can you please explain in a little more detail what isSupportMultipleVideos is doing? Sounds like it is checking for hardware capability as well as access to SAB.
Sounds like it is checking for hardware capability as well as access to SAB.
Yes.
Hardware capability is essential. As for SharedArrayBuffer, we provide an exception. You can specify the enforceMultipleVideos option in the client.init method if SharedArrayBuffer is not enabled.
Can you please share any other “minimum system requirements” needed for Video SDK for Web? This would be very helpful for me, and something I could share with our customers. Or a list of what qualifies as a low-performance device / “known limitations”?
Our goal is to support gallery view across all the devices are customers are using (which it used to work), so we’ll have to find another way because this is impacting a surprising number of our members. Anything you can share is helpful.
We’ve made some optimizations, and from the next version(Video SDK Web 1.12.0) onwards, devices with 2 cores will be able to support rendering 2 videos simultaneously.
There won’t be this limitation in the future version that supports the WebRTC video solution.
You can use the stream.isSupportMultipleVideos() method anytime to determine if the gallery view is supported.
