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

I’ve used the websdk sample app for angular. Apart from the lag in video (audio is fine), there’s a major issue of self video not appearing.

Here’s how you can reproduce:

  1. Start the call (1 host [0 participants] with audio enabled, video disabled)
  2. 1 participant joins in with audio enabled, video disabled
  3. Participant turns on her video, host is able to see and hear, but, participant can’t see her video (for a long time, or never)
  4. Participant switches tab to another website and comes back to the same tab with zoom, she is able to see her video now
  5. Participant turns her video off. Go to Step 3.

Tested on latest chrome.

Which Web Client SDK version?
SDK: 1.9.1
This did not happen before

Device (please complete the following information):

  • Device: Macbook Pro & Macbook Air
  • OS: Catalina & Big Sur
  • Browser: Chrome
  • Browser Version: Latest

Additional context
Please, I need an urgent solution, my complete platform depends on this.

1 Like

Hey @arpansac ,

Sorry to hear you are experiencing this issue, we are aware of it and working on a fix. (CS-3172)

That being said, do you see any errors in the browser console?


Thanks for your immediate response @tommy

There were no errors in the console when I was switching tabs. However, it was showing ‘video rendered’ or something similar (it was printed number times the count of participants in the video) every time I switched back to my Zoom app tab.

Any rough estimate as to by when we can get a fix? 120+ Communities are using my platform and are waiting for this fix desperately.

Also, is there an earlier version which is more stable to be rolled back to? (As this did not happen with 1.7 three months ago)

Hey @arpansac,

I understand this is a critical issue and we working with our engineering team to make sure we can provide a fix as soon as possible. However, I don’t have a timeline that I’m able to provide just yet.

In the meantime, you should be able to use version 1.8.6. My understanding is that this issue was introduced with version 1.9.0.

As using 1.8.5 or above is required, you can try using version 1.8.6 to see if that resolves the issue you’re seeing.

Let me know if that helps.


1 Like

Thanks @MaxM, let me try it out and update here.

Sounds good, let me know what you find.


@MaxM @arpansac was there any follow up on this… I’ve experienced the same thing occasionally and I can’t identify any rhyme or reason to it. I’m currently using version 1.0.3 of the Web Video SDK (not client sdk) fwiw.

Hey @victor.aprea,

Thanks for reaching out, try posting in our #web-video-sdk category with any relevant information to reproduce the issue and a subject matter expert will assist.



We are testing the 1.9.5 and facing a similar issue: it’s taking a very long time to show the video (own video as participant)
This does not happens all the time (but still something like 70% of the time), but as soon as it starts to happen for one session it happens all the time. It can take up to 2 minutes to show up after activating the video…

Any investigation results about this issue ? Looks like it’s not related to the SDK as already past version(s) were affected. More of a backend service issue maybe ?

Hey @nvivot ,

Thanks for reporting this is happening with 1.9.5. We are continuing to investigate the issue and will provide an update shortly.


Hey @nvivot ,

Are you using the Web SDK CDN or NPM? Can you confirm you are on the latest 1.9.5 across your system?

Also, you can apply for the Web Codecs Origin Trials, which provides access to better frame-capture APIs; this should help noticeably

If you can provide snippets of your Web SDK code, that’d be helpful too. The issue is unlikely to be a backend issue, as it most likely has to do with the frame-capture API


Hi Tommy,

We are using the NPM.

We recently upgraded to 1.9.5 and since Web Codec feature was buggy on the 1.9.1 we did not activated it yet. We have to test the 1.9.5 on the new features independently first, and then when a similar level as the previous version of quality is reached, we start to activate the new feature that may change the quality (for better or worse).

I’ll see with the testers to activate the Web Codec since we were planning to do it, but it should not be the solution here. Web Codecs are supposed to be optional right.

I’ll keep you informed.

Hey @nvivot,

Thank you for confirming, I’ve passed this along to Tommy and our engineering team.


Hi @MaxM,

Took a little longer due to other work commitments. 1.8.6 is having it’s own problems, viz.

It shows this on the display (after a few minutes when someone new tries to rejoin):

What do we do?

Really losing patience over this. I’ve literally had to convince the customers to have more patience as the zoom team is fixing it. It’s been more than 15 days already.

If this web sdk is not on priority, please do let me know because I’ll think in that direction.


Hey @arpansac,

Thank you for following up. I’ll start by saying that our Web SDK, and our development platform as a whole, are absolutely priorities of ours. However, there can be an extended timeline when investigating issues such as this to make sure that we correctly identify the root cause and fix the issue the first time.

In the meantime, as a workaround, try resizing the browser window to allow the view to display.

Thank you for providing more information on the testing that you’ve done. Have you had a chance to try implementing the Chrome Origin Trials as mentioned above?

If not, please let us know if that helps with the issues you’re seeing.

Further, often a fix for something relies on multiple pieces, some of which may be out of our control as Web as a platform quickly evolves.

I wanted to follow up with this point because it looks like I forgot to and it’s related to the previous point. while Origin Trials are optional, ultimately we recommend them because the Web platform is evolving so rapidly and using these Beta APIs will allow us to use the most up-to-date technology in hopes of avoiding issues such as this.

Using a different low-level codec can absolutely work around the issues we’re seeing here.


Talking about that, asking customers to try the Beta feature to see if it help is definitely not giving us confidence in your products. Especially when this feature was actually the source of many bugs in the previous version of the SDK (due to Chrome Version sure, but that clearly show you can’t ask your customers to use something in Beta and says it’s safe and going to fix things for you)

Hey @nvivot,

I can understand how it can be concerning to use Beta software. Ultimately, the Chrome Origin Trial Betas are recommended because they are cutting edge and can help alleviate problems that are industry wide.

More specifically, they aim to bring the stability and performance we know with native apps to the web platform.

This is a goal of the industry as a whole and every company that attempts to bring this level of AV functionality to the web would face similar challenges.

We aren’t requiring that you use the trials and it doesn’t mean we won’t help if they aren’t enabled but we recognize that enabling these new features is very likely to help to resolve issues which are for the most part industry wide.

Let me know if you have any questions.


Thanks for the update @MaxM
However, the app is in production mode and the users who love zoom are looking at the same seamless experience if they’re using the web embedded version of it.
I’ve seen that some websites say that ‘best in industry zoom integration’, are they facing the same problem?



Understood your point.

Let’s take the following example:

  • We have an application using the 1.8.5 web SDK on production
  • You release the 1.9.0, with new features but also new bugs (real SDK/service bugs + integration issues)
  • Because of that, we must wait for the fixes. In the meantime we report issues on the 1.8.5, and you ask us to upgrade to the latest version. We explain you we cannot for the mentioned reasons.
  • You publish the 1.9.1, with bug fixes and potentially new small features.
  • We start to test & integrate the 1.9.1. It takes time but finally we can perform the update to 1.9.1 in production.
  • But in the meantime, you already released the 1.9.5 with new features and again new issues (sdk/services bugs + integration issues)
  • We open new tickets about issues encountered on 1.9.1 and you ask us to upgrade to the latest version to see what’s happening. Again, for the same reasons, we explain that we cannot but are going to do our best to upgrade it.
  • We start to test & integrate the 1.9.5 and found several issues that we reported to you. This thread is about on of the issues, and the reply we get is to use a Beta feature that was source of errors and the Chrome 90, just a few days ago. Not investigation and fixes but to use something that may improve but would definitely not fix the root cause. Not mentioning that obviously this bug already happened on 1.8.6 and started to re appear recently on 1.9.5 but also 1.9.1. So it’s definitely not related to the SDK version or Beta features. Unless you recently patched your backend without saying anything making these Beta features a requirement. In such a case, please communicate on it instead of staying silent and asking to upgrade to the latest version + activate beta features.

On top of this, you can also add the fact that you also upgrade your backend independently of the Web SDK releases, which also introduces bugs and backward compatibility issues (we currently can see that on the 1.9.1 that suffers many video/camera issues when using the Pin/Unpin functionality while it was working fine a while ago…)

Do you see our point ? We don’t blame you for all the technical challenges you may face, but about the way your support (or do not) us - especially through the ticketing system - and the way you support (or not) your own products.

90% (just an estimation) of the reply flow we get for the tickets we open is something like this:

  • Please upgrade to the latest version and tell us if you still encounter the issue: we reply we cannot update right now, and you start to investigate
  • You reply that you found nothing on your backend / logs that would help to find the cause of the issue (meaning it’s not because of your backend). And again you ask to upgrade to the latest version.

I’m sorry but this is not enough. If you’re not able to point the potential cause of an issue within your software (no matter if it’s because of an internal issue or an external issue like network conditions), then improve the tracking & reporting of errors / anomalies.
Your software is not just about the backend, but also middleware (the gateway) and client side code. The client side is actually the part that will probably fail most of the time. But the error tracking & report on the client side is really poor.
As an example, i have asked for a year now if you can use a standard logging framework in your Web SDK instead of logging everything on the console. That would enable us to collect & send your logs to our monitoring platform so that we can easily track & report what happens on our clients’ browser to facilitate our and your investigation. And no reply at all in a year - yet ?

1 Like

Hey @nvivot,

Thank you so much for taking the time to write your post!

This is all a really great breakdown of how we can improve the developer experience here. I’m going to share this with my team tomorrow to get a discussion started. For the most part, we are working to address some portions of this but having your input is critical to ensuring these efforts are comprehensive and that they remain a priority.

I absolutely hear you and can relate to how frustrating the experience must be. Thank you for taking the time to explain that - you’re part of what makes this community so great.

I’ll continue our team’s discussion about how we can improve our support with your notes and let you know our next steps.

I just became aware of this recently and I’m sorry that I haven’t gotten to it yet. I know it’s an older request.

To be quite frank, I haven’t had time to address it since it was brought to my attention and I want to make sure that I handle it well because it’s a very valuable tool for developers and for us as we provide support. It is still on my To Do list but has had to be bumped down for one reason or another. I’m working to get to that within the next couple of days.