Continuing the discussion from [WebAssembly SIMD improvements - free discussion]

Continuing the discussion from WebAssembly SIMD improvements - free discussion

The original thread is closed, so here is a new one @nvivot

In chrome 86 or later, we should have the following experimental features ( to make websdk more performant:

  1. WebAssemblySimd
  2. WebAssemblyThreads
  3. WebCodecs

But in websdk 1.8.3, zoom still only enables 1 cpu core to decode video. As a result, it is dropping frames if the other side turns on screensharing or having 720p+ webcam.

websdk 1.9.0 should/could fix this but it could still be months away from being released.
This thread is finding ways to work around before websdk is “fast enough” some time next year. The solution could be some experimental chrome flags, or custom zoom av lib that can be set in setZoomJSLib (if zoom documents and allows drop-in replacement of better av simd encoding/decoding lib),etc.

Related posts:

  1. Meeting bad audio and bad video
  2. How to set receiving video quality to be lower like 360p
  3. Web SDK with low performance (Audio and Video)
1 Like

Thanks for creating an extension to the first thread.

It’s been a while now that i’ve run some tests on SIMD feature, but here is my understanding about the options we have as customers of the Zoom Web SDK.

WebAssemblySimd : this is the main feature and we can choose to activate it or not. I did it to run my tests and as mentioned on the other thread, i did not notice any significant improvement.
At that time, i was using the 1.8.0, so i’m going to redo some testing based on the 1.8.3.

WebAssemblyThreads : This is an option that would work if and only if the zoom WASM files are using multiple threading.
According to the information provided by Zoom on the previous thread, it does not seems that Zoom WASM programs are using it. They only use 1 thread per video and audio function (1 for encoding, 1 for decoding, this for both video & audio components)
So unless Zoom work on that part for a future version, there is nothing we can to by ourselves here to try to improve performances.

Here again, i’m afraid that the Zoom Web SDK is working with their own JS (or wasm) codecs. Not sure whether we can try different codecs by updating the path from the initialization code. I did not try yet and did not look into zoom documentation about this point. It would be nice to have Zoom highlight on that part as well.

It seems like 1.8.5 will be released tomorrow. Going to test that too. @nvivot please post some result. (I already tested 1.8.3 but I hope to get second pair of eyes on the same issue.)

For wasm threads, I also don’t see multi-core cpu helps. Only 1 core is active in video decoding, which is the most compute-intensive task. I would like to throw more cpu cores at this problem if possible. Zoom could open source the code that gets compiled to wasm.

For webcodecs, I am able to get video/audio data from websocket. But there is no way to modify as mitm.

I hope zoom can document some ways to swap in video/audio decoder. There are more efficient simd-ready h264 wasm decoders on github.


Could you please have a look at our comments regarding threads & web codecs and share our though with zoom devs ?

@tommy is there any change in simd support in 1.8.5? Just tested it, and the performance is essentially the same as 1.8.3.

Hey @tailinchu, @nvivot,

Thank you for continuing this discussion and sharing your thoughts and ideas! I will gladly pass this to our Web SDK engineering team! :slight_smile:

As for version 1.8.5 there were no changes related to simd support. You can enable WebAssemblySimd however. Jump to " SIMD Support".


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.