Web SDK with WebCodecs on 1.9.8 not showing user/participant video


Just for our clarification, do we still need to put the SharedBuffer Origin Trials and Web codecs headers in our code after updating the SDK?

Also, is this only for Mac devices? we were facing issues on Windows also. (The view button was replaced by the full screen icon)


Hey @helloparent ,

Just Shared Array Buffer and WebAssembly SIMD. :slight_smile:

It is for all devices using Chrome .

Thanks @lfrancia !



We did the below steps:

  1. Updated Web SDK to 1.9.9
  2. Put the headers Shared Array Buffer and WebAssembly SIMD in our code

The command typeof SharedArrayBuffer===‘function’ returns true. This came true only after putting the headers in nginx.conf.

We are able to see the View button that switched between Speaker/Gallery View. However, we are not able to Join Audio or Camera.

We are using React JS platform and don’t have any meeting.html or helper.html files.

@tommy @MaxM @lfrancia pease suggest what are we missing now?


Do you specify the SIMD feature as parameter on the prepare call ? (same for the web codec if you use it)

ZoomMtg.prepareJssdk([‘WebAssembly SIMD’]);

Would be easier to figure what can be wrong if you provide some code example. Only the part related to the web SDK (meta tag + react js code)

1 Like

Hi @nvivot

We tried adding this parameter also, but the issue remains the same.

Adding snapshots of the code example.

Don’t you have some meta tag definition somewhere (or headers) where you indicate the origin trial you are using on your app ?


Note: You will need one origin trial per domain name used to access your application. That’s why in my example there are twice per origin trial since we have two different domains to access our application.

But i guess your application was working before switching on the 1.9.9, is that correct ? Which version were you using before that ? I’m curious cause these two origin trial are almost mandatory since several weeks / months now, and should be used since version 1.9.0 if my memory is correct (for SIMD)

Another thing: what version of Chrome are you using for your tests ?
Could you check whether you have javascript errors when entering the meeting on your app ? (similar to what has been reported here for example and that would explain why you cannot join audio & video)

1 Like

Hi @helloparent,

Apologies for not replying sooner. nvivot, who is my colleague, already shared how we did it.

SharedArrayBuffer stopped working (video would stop working) from Chrome 92 if web isolation is not implemented on your application yet. So, as a temporary workaround, we used the SharedArrayBuffers Origin Trial on our application. As nvivot pointed out, you need to use the meta tag for the origin trial token. The token is per domain. So, if you have different environments (local, dev, staging, production), then you need to get tokens per each environment domain.


1 Like

Thanks @lfrancia, @nvivot for the response.

We have setup the SharedBufferArray and WebSIMD trials and added them to the nginx.conf file. We have also added the COEP and COOP headers as below:

We are using Chrome 93 for testing. Did not see any errors as mentioned by you in the console.

Please suggest.

Hey @helloparent ,

We have re written the Chrome Performance Improvement doc to make it more clear:

Please let us know if this helps! :slight_smile:


So, you officially do not support the credential less ? I though you mentioned it but in the end it’s not in the linked documentation.

Anyway, for anybody who want to understand web isolation & the different modes available, just go on chrome documentation. You won’t get a better and less confusing documentation than from the people who made it.

In your application, are you using 3rd party libraries that communicate with 3rd party services, or you own in-house services, that are not compliant with web isolation (they do not returns the expected headers in their HTTP response) ?
You should have some warning or error indicating that at least one part of your application cannot be isolated and therefore the web isolation is deactivated.
In such situation, even if you have the web isolation on your application, it will be dropped because of such 3rd party calls from your application, and because of the web isolation being deactivated, the SharedArrayBuffer will also be deactivated, making the Zoom Web SDK not working.

Now… if you have the SharedArrayBuffer Origin Trials, then you do not need to implement web isolation. Our application is working without.
What we did not test (and it seems to be your situation) is the usage of both the web isolation with potentially a 3rd party service not compliant (that would then affect the shared array buffer feature, with the shared array buffer origin trial. I’m not sure what would be the priority for Chrome between:

  • the deactivation because web isolation is deactivated
  • the activation because you use the origin trial

So, in your position, i would first remove the web isolation (since you use the origin trial), and test your application to:

  • check whether it works without the web isolation
  • check if you have a warning in the console log saying that the shared array buffer feature will require web isolation from chrome 93 (something like that, i don’t remember exactly the log message)

If you application works (audio & video), then you have your answer. If not, the problem is somewhere else and not related to web isolation.

Hi, @nvivot,

Thanks so much for sharing your insight - that was really helpful! We’re so appreciative of your feedback and help identifying issues. Massive gratitude to you!


Hi @nvivot

We tried removing the web isolation but then SharedArrayBuffer remains false. Below is the screenshot for the console

If possible, we can have a screen share also to go through the issue.


Hey @helloparent ,

Have you tried just using the SharedArrayBuffer Origin Trial?


Hi @tommy

We had tried to keep only the SharedBufferArray but then it remains false and the issue remains unresolved.

Did you verify that the Origin Trial for the Shared Array Buffer you are using apply for the domain name your are testing on ? Could it be an OT for another domain and therefore the OT does not apply.

When we apply the Web isolation trials along with COOP headers, the SharedBufferArray returns true. However, in that case, we are not able to join audio or video.

If you have shared array buffer when you activate web isolation, but not when you do not activate web isolation and use the shared array buffer OT, this confirm that your origin trial for shared array buffer is invalid.
An origin trial works for a specific domain / host name, and for a certain period. You should verify your current OT whether it applies to the correct host and is still valid (not ended). In all case, it’s probably easier to just re-create a token for this origin trial (with the expected host name), replace & test again with only the shared array buffer origin trial without web isolation. I don’t see any (obvious) reason for that not to work.

I suspect that your generated your shared array buffer origin trial before they extends the date to July 2022 (due to recent decision) and therefore, unless you renewed in between, the original date was until the end of Chrome 92.
Please renew it, and the validity / working period would be up to July 2022 for your new token.

Hi @nvivot ,

Thanks for your response. Our Trial was valid till Dec’21. But I still renewed the trial and updated the code with new token. (Below is the screenshot)

This still returns SharedBufferArray as false.

This is the console screenshot if this helps:



Another thing to note is that :

If I keep my Audio/Video On from the preview page, I do not get any error in the console. However, SharedBufferArray trials still remain false:

How do we get the SharedBufferARray trial to run true? Do we have to put any cross-origin related headers in the code to make this true?


Hey @helloparent ,

You do not need any cross-origin related headers.

All you need is a SharedArrayBuffer token and to put the token in a meta tag on your HTML pages: