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.
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.
WebCodecs:
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.
