Self video doesn't start/take minutes to appear, but participants able to view it immediately

Hey @nvivot,

As always, thank you for your patience. I wanted to let you know that your feedback is getting the attention it deserves internally and that it has spurred an excellent discussion about how we can improve our Web SDK support.

While I can’t share any specifics just yet, we have identified the root cause of why we’re missing the mark here and our team has determined action items to make sure that we are actively improving.

I’ll share more details with you here as they become available but I don’t have a timeline and I want to set the expectation that because this is a fairly substantial change the effects may not be immediate.

With that said, I’m still committed to making sure we provide excellent support in the meantime. I have responded to your feature request and I’ll continue working with our engineering team on our existing tickets.

I’ll be sure to follow up with you there ASAP.

Thanks,
Max

There’s a ticketing system? how did I miss that?

Hi @MaxM ,

Is there any update on this issue?

We have just tested a similar issue, wherein there is a delay in showing the user’s own video, on Web SDK 1.9.6 with SIMD and WebCodecs enabled and it seemed like it fixed the issue. However, a new critical bug was also introduced by WebCodecs, wherein screen sharing stops working properly. It is just sharing a black screen. (I will be creating a new ticket regarding this new issue).

So, because of this new critical bug, enabling WebCodecs is no longer one of our options now.

Could you please check on your side?

Regards,
Lara

Hey @lfrancia,

Thanks for following up on this. Can you confirm that you are also using the SharedArrayBuffer Origin Trial? This should allow you to utilize the most efficient API and also avoid the need for Web Isolation.

Let me know if that helps.

Thanks,
Max

Hi @MaxM,

Thank you for your reply.

Based on Zoom’s announcement, I thought we need to do both, SharedArrayBuffer and Web Isolation. Could you please confirm?

Regards,
Lara

Hey @lfrancia,

I think there is some confusion here. To clear things up there are two different paths forward:

  1. Web Isolation - this will allow the use of SharedArrayBuffer without an Origin Trial
  2. ShareArrayBuffer Origin Trial - this allows the use of SharedArrayBuffer without Web Isolation

Let me know if that helps.

Thanks,
Max

Hi @MaxM,

Thank you so much for clarifying that. You are right I got confused about the Web Isolation and SharedArrayBuffers Origin Trial. Let me clarify it a little bit more if you don’t mind.

So, basically, we either enable Web Isolation or register for SharedArrayBuffers origin trial (but this will only work until Chrome v.94 only) right?

And also, I am currently seeing this on our console logs and according to some articles that I have read, if I see this on my logs it means that the application is already using SharedArrayBuffer.

image

So, my questions are,

  1. Is Zoom already using SharedArrayBuffer on Web SDK 1.9.6? If yes, then we definitely need to enable web isolation or register for SharedArrayBuffers Origin Trial before July 20, 2021 right?
  2. If we don’t enable Web Isolation nor register for SharedArrayBuffers origin trial, how will Zoom Web 1.9.6 behave from Chrome v.92?

If I need to create a new thread, please let me know.

Regards,
Lara

Hey @lfrancia,

Awesome, I’m glad that helped. It was confusing to write so I completely understand that.

Yes, that’s correct except for one small difference. Currently, Chrome and the Web SDK use the SharedArrayBuffers API to provide the most efficient operation but this can vary based on the browser. Enabling the SharedArrayBuffers Origin Trial will ensure that the API is used now and continues to work in the future.

Based on the error message that you shared, it does seem that the browser is currently making use of the SharedArrrayBuffer API.

This was answered in part above but you will want to make sure that you enable the Origin Trial to keep using that API.

Really, the issues that you have been encountering seem like the result of not using this API - that is according to our engineering team. Effectively, the SDK would fallback on older, less efficient, API which could cause video/audio freezes and black screens.

As you make your move to 1.9.6 you should see significant improvement as well. The more I work with our engineering team the more I see the vast amount of improvements made with 1.9.5 and 1.9.6.

Thanks,
Max

Hi @MaxM,

We are only using Google Chrome browser for our meetings and since SharedArrayBuffer is already enabled by default right now (I understand it will stop working from July 20th - Chrome v92 release - since we haven’t enabled web isolation yet), the test result we got when we enabled web codec origin trial should be the same even if we also enable the SharedArrayBuffers Origin Trial right?

Regards,
Lara

Hey @lfrancia,

Assuming that the SharedArrayBuffers API is already being used then yes that’s the case but our team has heavily recommended the SharedArrayBuffers Origin Trial so I think it’s a good next step.

Even if you don’t see a difference, I can then demonstrate your issues on the latest version with the best configuration which should help to identify any hidden issues.

Thanks,
Max

Hey @MaxM, I don’t mean to butt in on the thread (and happy to create a new one instead if required) but I wanted to say that the steps that have been provided in the announcement as well as on the advanced guide do appear to suggest opting into the origin trial as well as enabling web isolation, so if that’s not the case then may I suggest they’re updated?

My understanding is (and please correct me if I’m wrong!) that the origin trial for SharedArrayBuffers acts as a bridge to extend the timeline for those who can’t change their apps/sites over to use Web Isolation in time for Chrome 92, where the SharedArrayBuffers API is disabled in non-isolated domains. So if you’re able to switch over to using COOP and COEP then happy days, your application can leverage the APIs that require the additional security and nothing should change - but if you can’t, then add the Origin Trial until you can. But ultimately, you will need Web Isolation as the trial is finite.

If we need to have the origin trials - either for the SharedArrayBuffer or for better performance on showing/hiding videos - then that’s going to cause problems for anyone who supports multiple domains as you need to register each domain with the trial key upon registration for that key. My platform allows users to use either a provided sub-domain (in which case we can apply a token at the top level domain and include all sub-domains) or their own domain (which is where things get tricky), so what is the suggestion here? My best attempt at finding a solution is that we’ll need to register for a special token as stated in the origin trials FAQs talking about embeddable content on different domains but I have yet to find how to get in touch for this limited basis token, or if one would even be available.

Also @lfrancia, I suggest running your zoom application with Chrome Canary as that’s currently running Chrome 93 and should give you an idea of what works and what does not. As an example, I noticed that the speaker and gallery view disappeared when the application was not using COOP/COEP and had no Origin Trial key.

Apologies for the wall of text, but hopefully it’s understandable.

Cheers!
Mike

Hi @mijodu,

Thank you for your suggestion and your input into this topic.

Yes, I have already tested our app with and without the sharedarraybuffers origin trial on Chrome v.93 yesterday. I was able to see the difference like the user’s own video is not shown on his/her own side despite the video being enabled and streamed to the other user when the SharedArrayBuffers Origin Trial is not enabled.

So for now, we will just enable the SharedArrayBuffers Origin Trial on our application while we are working on our app’s web isolation.

Cheers,
Lara

Hi @MaxM,

I have just tested our application with both the WebCodecs and SharedArrayBuffers Origin Trials enabled and here is the result.

Could you please confirm it as well?

Regards,
Lara

1 Like

Hey @mijodu,

Thank you for reporting our documentation issue and for providing your insight here!

That is absolutely correct and a great explanation of how our documentation is currently incorrect. I’ll work with our team to make sure this is updated.

That’s correct, I think for the time being the Origin Trial is really the only option. We are looking into supporting multiple domains with this in the future but I don’t have a timeline or concrete details for you just yet.

That’s a great suggestion!

Thanks,
Max

Hey @lfrancia,

I’m glad to hear that resolved this issue at least, I’ve followed up with you in the new thread.

Thanks,
Max

Hi @MaxM,

Here is just an update on the video delay issue. I have just tested it on a MacBook Pro machine (macOS Big Sur v.11.2.3) with Web SDK 1.9.7 and chrome v.92. It seems like there is a 2 secs delay in showing the user’s video both on his screen and to other participant’s screen. On, a windows machine, there was no problem.

Although the delay is not as long as the original issue reported, there is still 2 secs delay.

Regards,
Lara

Hey @lfrancia,

Thanks for following up on this. I’ve created a new ticket to have this behavior investigated. I’ll let you know what I hear from our team. (ZOOM-297273)

Thanks,
Max

Hey @lfrancia

This sounds super cool, can you please point to some docs which will help me to test this too.
I started this thread, but haven’t been able to follow through for some time (disabled zoom meetings on my platform for now).

Thanks!

Hey @arpansac,

If you are looking for steps to enable Origin Trials you can follow this guide:

Let me know if that helps.

Thanks,
Max

Hi,

You can check the documentation shared by @MaxM on how to register for the origin trials. For the WebCodecs you need to do an extra step though. You need to specify WebCodecs in the ZoomMtg.prepareJssdk too.

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

Regards,
Lara