Unable to view clients on android: ICustomizedVideoSink Error

Meeting SDK Android v5.16.5.17050

We are currently developing a custom grid view utilizing a recycler view and incorporating our layout that includes MobileRTCVideoView. To associate the viewHolder with the video content, we follow this process:

    new MobileRTCVideoUnitRenderInfo(
    ).apply {
        is_border_visible = true;
        is_username_visible = true;

At times, we encounter an issue where certain users’ cameras are not visible, particularly when there are more than 8 Android clients and several web clients (average of 20 users per meet). To address this, we have implemented an ICustomizedVideoSink listener to log potential errors occurring in the process.

One specific error we observe when binding the views is the inability to see the user’s camera. The error details are as follows:

  • errorCode: 6 (zoomSDKVideoSubscribe_Fail_HasSubscribeExceededLimit)
  • size: 4 (the significance of this value is currently unknown)
  • userId: XXXXXX (the user ID matches the one bound to the layout)

We are seeking assistance to understand and resolve this issue. The error code zoomSDKVideoSubscribe_Fail_HasSubscribeExceededLimit suggests a limit on video subscriptions, but the exact nature of the limit and its impact on the visibility of certain users’ cameras remains unclear.

If anyone has encountered a similar issue or has insights into the meaning of the “size” parameter in this context, we would greatly appreciate your input. Additionally, any guidance on how to address or work around this limitation, especially when dealing with a larger number of Android and web clients, would be invaluable.

Thank you in advance for your support and expertise in resolving this matter.

@efren when you are subscribing to these videos, what are the resolution you are requesting for?

Hi @chunsiong.zoom,

We haven’t defined the resolution anywhere; the app uses the default setting. Additionally, we’ve kept the aspect_mode as the default: VIDEO_ASPECT_ORIGINAL - 0.

@efren , you might want to see if there is a way to reduce the subscribed resolution. there is a limit to how much high resolution videos you have subscribe to at a single point in time, conversely if you are subscribing to lower resolution videos, you can subscribe to higher quantity of them

1 Like


We tried to use the method zoomSDK.meetingSettingsHelper.enable720p(false), but it didn’t resolve our problem. Also, we attempted to implement the raw data approach demonstrated in your demo app, but we couldn’t use it because zoomSDK.hasRawDataLicense() returns false.
Could you please guide us to the appropriate implementation to reduce the resolution of the video?

Thank you in advance

Hi @chunsiong.zoom,
We are currently grappling with a persistent issue and have exhaustively explored various paths outlined in the documentation to resolve it. The problem persists even when utilizing the WebSDK in our web page. Specifically, as we upgrade the grid view to 25 elements, we encounter rendering issues where some elements fail to display properly.

We would greatly appreciate any insights, suggestions, or alternative solutions you may have to address this issue.

Thank you in advance for your assistance.

@efren for web SDK to display 25 videos, there are specific conditions to follow outlined here

For Client SDK, the general rule of thumb is here

At most 34 90p video subscriptions in a meeting,
At most 17 180p video subscriptions in a meeting

Hello @chunsiong.zoom,

You’ve informed us that we need to lower the video quality, but we’re still unsure how to do it as we couldn’t find any references in the documentation for implementing this on Android. Do we need to configure the room somehow on the backend, or is it each device managing its video quality upon entering the room?

If the limits you mentioned are 34 at 90p or 17 at 180p, what is the default maximum number of subscriptions we can have? Is it around 9-10? Do we need to generate some subscription rotation for users to avoid saturation?

We are currently in production, and this issue is causing a lot of disruption to our users. We need an update as soon as possible, or we might have to discontinue using your services.

We eagerly await a concise response with a solution as soon as possible.