Very high CPU load, audio/video problems for Web SDK

Hi,

using your latest web SDK 1.7, we are getting very high CPU loads on our platforms.
This was acceptable on our ‘stronger’ models, but is very bad on our ‘low-end’ model
(nevertheless a 4x core Intel cpu i3-7100U CPU @ 2.40GHz), as video / audio begins stuttering
and/or A/V is out of sync

the zoom application is basically the only application running on the machine, occupying the CPU
most of the time.

if muting VIDEO from the local side (where we see the performnace problems / high cpu load), we receive audio / video in acceptable quality and delay (between audio/video)

suspecting from the WASM section of your API description: preLoadWasm() and also by observing GPU load(which is not changing when starting up zoom JS), we suspect that you do all the en/decoding in JS?

also: using the ‘normal’ browser based webapp in chromium 78 (i.e. the non-JS SDK client), the platform in question delivers sufficient audio/video quality and delay.

  • Is there any possibility to improve this, by e.g. using different webassemblies, restricting resolution, …?
  • are there plans to improve this performance issue in an upcoming JS SDK version?
  • switch to chromium based en/decoding, instead of JS code?

thx
Hari

3 Likes

Hey @harald.glanzer,

May I ask what country you are located in, and if you are using the CDN or Local version of the Web SDK?

Thanks,
Tommy

hi,

we are located in austria / europe, and are using the local version 1.7.0.

a colleague of mine, located in north germany, can’t reproduce the problem with the same platform. he reports that his cpu load is much lower, and audio / video quality is ok and in sync.

are you using different encoders / resolutions, depending on the country?

thx
hari

Hey @harald.glanzer, thanks!

Can you send me the meeting id used so I can look into the logs?

Thanks,
Tommy

for example: 5398465177

thx
hari

Thanks @harald.glanzer,

We are looking into this and will get back to you. (ZOOM-137004)

Thanks,
Tommy

hello again,

i compared the SDK and the in-browser clients on the platform in question. it turned out
that the in-browser client (i.e. the link ‘join from your browser’) produces much better results than the SDK client:

in browser client:

  • smaller cpu load
  • higher gpu load
  • good AV quality, good A<–>V delay

sdk client:

  • high cpu load (busiest zoom thread needs almost one CPU for its own)
  • nearly unaffected gpu load
  • unacceptable A<–>V delay / video lag

questions:

  • is your SDK client using GPU for en/decoding?
  • is there any possibility to use a different video encoder (via setZoomJSLib() call) with different resolution / framerate
  • is it possible to check which resolution / framerate is used for a specific meeting attendee, or globally for the whole meeting?
  • are you aware of such a ‘cpu load’ problem, regarding the SDK client?
  • when will you release your next SDK version 1.8.0, and will there be improvements regarding this problem?
  • are there any news regarding my last request (ZOOM-137004)?

thx in advance,
hari

Hey @harald.glanzer,

We are in the process of looking into (ZOOM-137004).

"The Web SDK enables the development of video applications powered by Zoom’s core framework inside an HTML5 web client through a highly optimized WebAssembly module.

As an extension of the Zoom browser client, this SDK is intended for implementations where the end user has a low-bandwidth environment, is behind a network firewall, or has restrictions on their machine which would prevent them from installing the Zoom Desktop or Mobile Clients."

CC @JackYang, can help answer this one.

Not at this time.

The meeting resolution will have a max of 360p: https://marketplace.zoom.us/docs/sdk/native-sdks/web

“Currently, the Zoom Web SDK encodes at a maximum resolution of 360p. If a user is in a meeting with both native and browser clients, the browser client video displayed within the native client will be of lower quality due to encoding limitations.”

We are not, but we are investigating your issue.

If this is a bug, then yes we will work on fixing it in an upcoming release.

Thanks,
Tommy

thx for your detailed answer. if i can assist somehow in debugging this issue, please tell me!

regards,
hari

1 Like

Hey @harald.glanzer, happy to help!

I’ll let you know if we need additional info!

Thanks,
Tommy

hi again,

any news here?

thx
hari

Hey @harald.glanzer,

No updates yet. After we look into this, we will get back to you.

Thanks,
Tommy

Any updates on that?
My computer is really unusable when I open Zoom at this moment.
Here’s my CPU load when I use Zoom:

Screen Shot 2020-05-08 at 18.13.42

Hey @mateus.gomes,

Can you please share what kind of computer you have and the specs so we can investigate?

Thanks,
Tommy

I am seeing the same spike in cpu load when a zoom call begins.

I have a macbook pro 15-inch. 2.8 ghz i7 16gb memory

1 Like

Hi, this thread follows an issue I’m also having. We are using a custom built i7 7700k 4 core. 16 gb of ram. We are using the on-board graphics with no dedicated gpu. There are high cpu loads once we connect to audio or video, and both at the same time.

The issue was repeatable, on a fresh install on windows 10, whichever the latest build is.

Hi @tommy ,

We are also facing the same CPU spike issue which is quickly draining the battery and produce more heat. CPU % was went up to 80%. We are accessing from India.

We used the latest Web SDK 1.7.7 both CDN and Local.

Google Chrome Version 81.0.4044.138 (Official Build) (64-bit)

macOS Catalina Version 10.15.3 (19D76)

MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports)

Processor 2.3 GHz Dual-Core Intel Core i5

Memory 8 GB 2133 MHz LPDDR3

Graphics Intel Iris Plus Graphics 640 1536 MB

3 Likes

Using the zoom client, I am also getting very high cpu usage. On a Lenovo T590 (4k resolution), viewing with full screen results in >100% cpu usage on ubuntu 20.04. Rescaling the window to a smaller size can get the cpu down to 30-50%.

same problem here… my mac doesn’t run anything else when in a zoom meeting

1 Like

Hey @gborges, @s.tootle, @karthikeyan.ramaraj, @spongiephone, @pierre.a.lafortune,

Thanks for reporting this. I will forward these details to our Web SDK engineers. (CS-1387)

Thanks,
Tommy