Meeting SDK Type and Version
zoom-meeting-sdk-linux_x86_64-6.1.0.225
Description
Subscribe to multiple raw video streams.
I am using a IZoomSDKRenderer instance and subscribe to multiple participants at the same time.
On the ZoomSDKRenderer::onRawDataFrameReceived callback I noticed that I am getting data only for 2 participants at the same time while I am subscribed to 8 participants.
I noticed that if I set a lower resolution (or if I turn off the Meeting-HD Video Quality flag ) I am getting data from more participants at the same time
videoHelper->setRawDataResolution(ZoomSDKResolution_360P);
vs
videoHelper->setRawDataResolution(ZoomSDKResolution_720P);
This way I got response from the onRawDataFrameReceived for more participants.
Looks like this is a limitation on the delivered data from Zoom based on the requested quality of the video, is this correct?
Is it possible to increment the number data delivered for parallel participants on the onRawDataFrameReceived callback for HD video?
Error?
No errors
Troubleshooting Routes
There is a difference between the delivered data if we increment the resolution of the videos, I think that this might be a limitation on the bandwidth from zoom.
How To Reproduce Steps to reproduce the behavior including:
Subscribe to multiple participants using a IZoomSDKRenderer instance
Check the onRawDataFrameReceived delivered data
Only a fraction of the subscribed instances get data on the callback
We use the Linux SDK to run meeting bots at scale and are very familiar with the issue you’re facing.
You can definitely have more video streams but you are capped on bandwidth. So if you need more participants you need to subscribe to each participant at a lower resolution.
In this documentation, Zoom states you can have up to 34 participants per screen and 49 total. Since the main constraint is bandwidth, you’ll need some logic to determine the optimal resolution based on the number of participants and screensharing. Based on the above constraints and our own experience, a good way to think about this is that you have a constraint of 34 90p video streams (the default mentioned in the above article). For instance, capturing a 720p screenshare is equivalent to 32 90p streams, and a 180p video stream is equivalent to 2 90p streams.
An alternative to consider:
If you don’t want to worry about these details and instead want to focus on building your core product, one alternative is to use Recall.ai. It’s a simple 3rd party API for meetings bots that allows you to get raw video/audio and other data in just a few lines of code, without having to worry about the low level details and managing infrastructure yourself.
Just wanted to let you know about an open source meeting bot API similar to Recall called Attendee. You can checkout the github here: GitHub - noah-duncan/attendee: Meeting Bots made easy. It is free and easy to self-host.
It currently only supports fetching the video feed of the active speaker, but we are constantly adding new functionality. If you are interested in using it, but it lacks the functionality you need, post an issue in the repository with a description of your use case and we will add it soon.