Description
We are integrating the Zoom Web Video SDK into a Flutter Web (Single Page Application). To support the WebAssembly and SharedArrayBuffer features such as the Virtual Background (and optimal video/audio processing), we have configured our server to return headers for Cross-Origin Isolation:
However, our application also needs to embed a third-party partner’s application inside an iframe. Since this third-party server cannot add HTTP response headers like Cross-Origin-Resource-Policy: cross-origin (CORP) to their resources, the browser blocks the iframe due to COEP violations.
If we change our headers to COEP: unsafe-none to allow the third-party iframe, Zoom’s virtual background module fails to load because SharedArrayBuffer becomes unavailable.
We would like to ask:
Is there any way/workaround to utilize the Zoom Web Video SDK (including the Virtual Background feature) without requiring Cross-Origin Isolation (COEP: credentialless or require-corp)?
Or is there a recommended architecture/workaround to embed a third-party cross-origin iframe without CORP headers while keeping Zoom’s SharedArrayBuffer features active in a Single Page Application context?
Which Web Video SDK version? 2.2.12
To Reproduce(If applicable)
Steps to reproduce the behavior:
Deploy the host web application with the following HTTP response headers:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: credentialless
Initialize Zoom Web Video SDK and try to enable Virtual Background (it works as expected).
Try to embed a cross-origin <iframe> pointing to a website that does not return the Cross-Origin-Resource-Policy: cross-origin header.
See the net::ERR_BLOCKED_BY_RESPONSE error in the browser console, and the iframe content is blocked from loading.
Troubleshooting Routes
Tested setting COEP: unsafe-none: The third-party iframe loaded successfully, but the Virtual Background feature in the Zoom SDK failed to initialize because SharedArrayBuffer was disabled.
Attempting route-specific headers in SPA: Since it’s a Single Page Application, dynamic header changes per route require a full browser reload when transitioning between pages, causing flickering and state management issues.
Device (please complete the following information):
Device: [e.g. Windows PC / iPhone]
OS: [e.g. Windows 11 / iOS 17]
Browser: [e.g. Chrome / Safari]
Browser Version [e.g. 120.0.0.0]
Additional context
The web app is built using Flutter Web (compiled to JS).
Changing headers on the third-party partner’s server is completely out of our control.
Is there any way/workaround to utilize the Zoom Web Video SDK (including the Virtual Background feature) without requiring Cross-Origin Isolation (COEP: credentialless or require-corp)?
Since Video SDK version 2.4.0 , Virtual Background no longer requires SharedArrayBuffer. We recommend upgrading to the latest version to resolve this issue. Also, when SharedArrayBuffer is not available, we will use the WebRTC video solution by default, which provides a better user experience as well.
I noticed that the updates from version 2.2.12 to 2.4.5 include changes to WebRTC and the core SDK.
Could you please confirm if this upgrade might impact performance? Specifically, I would like to know if there is any risk of increased resource consumption, lag, or degradation in audio/video quality.
Any confirmation or additional details regarding performance changes after the update would be greatly appreciated.
Besides the Virtual Background feature, could you please let us know what other SDK features will be impacted or limited if we configure COEP to unsafe-none (such as gallery view limits, background noise suppression, etc.)?
Could you please confirm if this upgrade might impact performance?
Our versions are backward compatible, and they will not increase resource consumption or cause any audio/video quality issues.
In addition, for features such as gallery view and background noise suppression, when SharedArrayBuffer is not enabled and the WebRTC video solution is automatically used, these features are not degraded and are still fully supported.
In this fallback scenario, what is the expected impact on
Virtual Background
WebAssembly supports Virtual Background even without SharedArrayBuffer. The only impact is that if hardware acceleration is not enabled on the device, for example if Chrome’s “Use graphics acceleration when available” setting is turned off, or if you are using a cloud VM without a dedicated GPU, such as Amazon EC2, then Virtual Background will not be available in those cases, and isSupportVirtualBackground() will return false.
Technically, though, we already support this scenario. It’s just that this feature is still in beta and is only available to a limited number of customers at the moment.
Gallery View & Noise Suppression
Noise suppression is supported as well.
Gallery View can be supported in the WebAssembly + no SharedArrayBuffer case by specifying the enforceMultipleVideos option in the init method.
Thank you for the detailed explanation. This information is very helpful!
Just to summarize and confirm my understanding of the fallback behavior:
If SharedArrayBuffer (SAB) is unavailable: It falls back to WebRTC, where Virtual Background and Gallery View will continue to operate normally.
If both SAB and WebRTC are blocked: It falls back to WebAssembly without SAB. In this scenario, Virtual Background still works (provided hardware acceleration is enabled), but Gallery View will be limited to a maximum of 4 video frames (up to 3 others + 1 self).
Please let me know if I missed anything. Thanks again for your support!
We are having similar issues with our application and using virtual background on FireFox. Without SAB headers enabled the performance of the virtual background when enforced is very poor and choppy but we are unable to enable the SAB headers needed due to integrating with 3rd party iframes.
Is there a known work around for this or do we just have to disable virtual background on Firefox and Safari?
For the performance issue when using virtual background without SharedArrayBuffer, you can choose to use the default WebRTC video solution.
At the moment, Firefox’s WebRTC video support is still in beta and is being rolled out to only a small number of accounts, but other browsers include Safari should have WebRTC video enabled by default.
Yea Safari seems to perform fine with the current set up and it is just FireFox right now that is giving us issues.
The default fallback is happening with FireFox using WebRTC but this does not fix the performance issues when virtual background is enabled.
Is this a case of potentially just disabling the option for virtual backgrounds with FireFox for the time being until the browser fully releases full WebRTC video support? Do you know if they have any time line on this?
Is this a case of potentially just disabling the option for virtual backgrounds with FireFox for the time being until the browser fully releases full WebRTC video support?
If you think the performance is not meeting expectations, you can temporarily disable virtual background on Firefox.
As for WebRTC video support, there is not yet an exact timeline. We will move it to GA once we have completed sufficient testing, and it should not take too long.