Release 1.8.0 of Web SDK includes changes to support latest WebAssembly SIMD feature on Chrome 84+
This is supposed to bring improvements on CPU usage as well as probably improve video quality (we still have to determinate what we understand & mean by quality)
What is SIMD ?
For those who are not familiar with, here is a good technical explanation about what it is and what we can expect in term of improvement.
After performing few tests on our platform (with SIMD feature activated on all our web pages using Zoom), we could not notice any improvements.
Did we test it correctly ? Did we measure and monitor correctly ? Did Zoom really use SIMD in a correct way, did Zoom change the way to use CPU with the Web SDK or not ?
Many questions and that’s why i want to open that discussion here.
In particular i would like to clarify the following points with you (community & users as well as Zoom developers)
For Zoom developers:
What kind of improvement this feature is supposed to bring for the zoom Web SDK ? (performances, support for 720p, etc.) (please let’s stay honest, the point of this thread is not to just promote new things by throwing a smoke screen but really help us to understand where you are going with the Web SDK)
How can we - as users of Zoom Web SDK - monitor these improvements ? Clearly current Zoom Meeting Dashboard metrics are not working very well (it show video streaming for minutes even after a use left and its connection has been terminated for example) - not talking about the fact that we cannot monitor CPU usage there.
What kind of tests did you perform ? Can we have access to them and their results ?
SIMD itself enable to improve things, but only if you adapt your video encoder. So what did you do to be able to use SIMD and bring the improvement you mentioned ?
For Zoom community:
Have you already tested SIMD improvements ?
If so, how did you monitor it and what is your Zoom Web SDK use case(s) ?
What do you expect as improvements ? (lower CPU usage due to better resource usage, still same CPU burst but enable to encode in 720p soon, no CPU usage improvement but more video stability, etc.)
For instance, the High CPU usage issue is dependent on Chrome releasing the WebAssembly SIMD feature for Chrome 84 on July 14th. This helps drastically reduce the CPU usage for meetings. We are still performing internal testing to make sure the SIMD feature meets Zooms standard, once we’re finish testing we will release a new version.
CPU usage should drastically be reduced. I was really happy to see that announcement since we face some difficulties when users run Zoom Web SDK on low CPU spec machines.
Our expectation were big, as our deception after testing. CPU usage remain the same (high and bursting as hell)
Let’s be clear, just enabling the SIMD support and upgrading to the latest Chrome version is not enough. It also depends on how the encoder has been implemented.
Here are my questions:
what did you change on the encoder to support and use SIMD capacities ?
how can we monitor the improvement compare to let say version 1.7.10 without SIMD support ?
could you describe what how CPU is used in the Web SDK ? (use as many threads as you can, use only 1 thread for video encoding but full resources without any pause, etc.)
Thanks for taking the time out to ask these important questions and opening up a dialogue for WebAssembly improvements.
The SIMD feature was introduced by Chrome to help reduce CPU usage when using Web Assembly. Keep in mind that this is in trial mode until November and is constantly being improved by the Chrome team and Optimized by Zoom team.
Currently we do not offer any features to monitor the CPU usage, we’re looking to improve our analytics across the platform. However, we do offer a way to check to see if the SIMD is in use within the console log.
We’re testing across multiple machines such as Macs, Windows, Linux, Chromebook with different processing & memory specs to see if the CPU usage and Encode/Decode performance improves.
Here are the scenarios when using encode/decode for threads.
* audio encode — one thread
* audio decode — one thread
* video encode — one thread(without 720p)
* video decode — one thread(only for active view)
* sharing encode — one thread
* sharing encode — one thread
When we detect the browser can run SIMD instructions, we will download a wasm code that is written by SIMD.
Please let us know if you have any other questions.
I’m glad to have more details and can now understand why the Zoom Web SDK cannot perform well on low CPU specifications.
I still want to clarify something with you.
The way you answered make me think that you are not using multi-threading, only parallel processing.
Let me explain more about it:
You separated each data processing functionalities so that they can be processed separately and in parallel, and this is a good thing. But still, this is parallel processing but not parallel multi-threading processing.
If we take the audio decode thread as an example, it means that if this thread is suspended by the user’s computer then there is no audio decode anymore.
At least from our experience and monitoring of the Web SDK, this would explain why the video processing still continue to affect the audio processing even if they are processed by distinct dedicated threads. In case the CPU of the machine is over loaded then some processes can be paused.
If i take an example based on my programming experience in Java, it looks like you are using classes which extends Thread class to execute the code, instead of switching to more modern multi-threading engine or a wrk-steal based framework (just for the comparison)
Is my understanding correct ?
I don’t know about video processing, but some framework recently improved their performances doing WASM + multithreading. Is it something you’re working on ?
Also, what is the thread priority in the system when they are created ? Compared to other threads run on the user’s system, but also between all your threads ? This could also affect the pausing / restarting priorities between threads when the CPU is overloaded.
Sorry to bother you with such details but i like to understand how things work and try to improve them or find workaround about how to use them the best.
By the way, i did not pay attention, but about this remark:
When we detect the browser can run SIMD instructions, we will download a wasm code that is written by SIMD.
You better download it if the browser is compatible AND the feature is activated. (easily achievable with js code)
There is no need to download it if it’s not activated, which is probably the case on most of browsers since this is still experimental feature.
