# Subscribe video counts greater than maximum size

**URL:** <https://devforum.zoom.us/t/subscribe-video-counts-greater-than-maximum-size/121500>\
**Category:** Video SDK\
**Tags:** video-sdk\
**Created:** [November 25, 2024, 9:09pm UTC](https://devforum.zoom.us/t/subscribe-video-counts-greater-than-maximum-size/121500 "2024-11-25T21:09:23Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mauro.barrionuevo](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/mauro.barrionuevo/32/50470_2.png) [@mauro.barrionuevo](https://devforum.zoom.us/u/mauro.barrionuevo)\
**Post date:** [November 25, 2024, 9:09pm UTC](https://devforum.zoom.us/t/subscribe-video-counts-greater-than-maximum-size/121500/1 "2024-11-25T21:09:23Z")

</div>

**Video SDK Type and Version**  
Web Video SDK v1.12.5

**Description**  
We are tracking numerous errors of the following type in Sentry, occurring across a wide range of devices. The error appears concurrent, and the number in parentheses varies from 1 to 4 depending on the device type.

The issue predominantly occurs in Gallery View, where users consistently see only 2 out of 9 participants rendered. Shared Array Buffer is enabled, and we are using “credentialless” headers. When checking `isCrossOriginIsolated` on the browser, it returns `true`.

This issue happens in nearly every session we run. For reference, a sample session key is: `DKXEA1zPSXCfbXAzg4uuBw==`.

**Error Details**

```auto
{
  reason: subscribe video counts greater than maximum size (4),
  type: INVALID_OPERATION
}

```

**Troubleshooting Steps Taken**

- Adjusted headers to `require-corp`, but the issue persists.

**Steps to Reproduce**  
This issue occurs on a wide range of devices and browsers, including:

- Windows and macOS
- Android and iPhone
- Linux

It appears regardless of platform, making it difficult to isolate specific conditions.

---

<div class="post-metadata">

**Author:** ![rehema.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/rehema.zoom/32/40323_2.png) [@rehema.zoom](https://devforum.zoom.us/u/rehema.zoom)\
**Post date:** [November 26, 2024, 3:37pm UTC](https://devforum.zoom.us/t/subscribe-video-counts-greater-than-maximum-size/121500/2 "2024-11-26T15:37:55Z")

</div>

Hi, @mauro.barrionuevo ,

This error can be explained/resolved using the same solution in this thread. Please see [here](https://devforum.zoom.us/t/subscribe-video-counts-greater-than-maximum-size-4/113916/5).

---

<div class="post-metadata">

**Author:** ![mauro.barrionuevo](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/mauro.barrionuevo/32/50470_2.png) [@mauro.barrionuevo](https://devforum.zoom.us/u/mauro.barrionuevo)\
**Post date:** [November 26, 2024, 7:05pm UTC](https://devforum.zoom.us/t/subscribe-video-counts-greater-than-maximum-size/121500/3 "2024-11-26T19:05:41Z")

</div>

Thank you, Rehema, for your answer.

I understand that the linked solution applies when Shared Array Buffer (SAB) is disabled. However, in our case, SAB is enabled. Does this solution also apply to scenarios where SAB is enabled? Specifically, will it allow us to render more than 2 or 4 videos, depending on the device?

If that’s the case, could you clarify the benefit of having SAB enabled in this context?

---

<div class="post-metadata">

**Author:** ![vic.yang](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/vic.yang/32/24656_2.png) [@vic.yang](https://devforum.zoom.us/u/vic.yang)\
**Post date:** [November 27, 2024, 2:53am UTC](https://devforum.zoom.us/t/subscribe-video-counts-greater-than-maximum-size/121500/4 "2024-11-27T02:53:25Z")

</div>

Hey @mauro.barrionuevo

Thank you for your feedback.

> DKXEA1zPSXCfbXAzg4uuBw==

After analyzing the logs, we found that the error occurred on an Android device (I suspect it might be an Android phone). For performance and safety considerations, we have a default limit of a maximum of **4** renders.

This can be adjusted by setting the `enforceMultipleVideos` option in the `init` parameter to `disableRenderLimits: true`.

Good news is that our upcoming WebRTC solution will no longer have this limitation.

Thanks  
Vic