I have developed a bot that extracts video from each participant in a Zoom meeting using the Linux SDK. For each participant, the bot creates a new renderer and processes frames in the onRawDataFrameReceived callback. This setup performs well in meetings with 4-5 participants, where I successfully receive and process video data at a resolution of 360p for each participant.
However, issues arise as the number of participants increases. Specifically, in larger meetings, onRawDataFrameReceived sometimes does not receive data consistently for all participants, and occasionally the data for certain participants is missing entirely.
I am seeking insights into the limitations of Zoom’s video processing capabilities, especially related to the Linux SDK:
Is there a known limitation on the number of video streams that can be processed simultaneously by Zoom’s Linux SDK?
Could network bandwidth or system performance issues be causing this inconsistency in data reception?
Are there any recommended best practices or configurations for handling larger meetings effectively using the Linux SDK?
Any guidance or advice on how to manage these challenges and ensure stable performance across meetings of any size would be greatly appreciated.
We use the Linux SDK extensively to power our meeting bots and have run into similar questions when it comes to video streams and larger meetings.
Is there a known limitation on the number of video streams that can be processed simultaneously by Zoom’s Linux SDK?
Could network bandwidth or system performance issues be causing this inconsistency in data reception?
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.
Are there any recommended best practices or configurations for handling larger meetings effectively using the Linux SDK?
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
You could also consider using the Recall.ai API for your meeting bots instead.
(I might be a little biased as one of the founders of Recall.ai, but our API powers over 400 companies, and would love to help you too)
It’s a simple 3rd party API that lets you use meeting bots to get raw audio/video from meetings without you needing to spend months to build, scale and maintain these bots.
I have another question, it is possible to identify a meeting participant in a unique way? I checked the userId and userPersistentId and both are changing between different meeting sessions.
@amanda-recallai I used Recall.ai to obtain live video streams of individual participants in a video call. However, I was only able to retrieve video feed for 22 participants out of a total of 36. Is this the limit of Recall? if yes, is there a way to increase this limit?
I followed the documentation (Receive Real-Time Video: Websockets) where I received the video frames via websocket.