Hello,
as already written here, your Web SDK is not useable on a modern 4core i3-7100U CPU with 2.4GHz with your maximum supported resolution of 360p (which is not high anyway).
Even an Intel 4core i3-8109U 3GHz needs to go constantly to ‘frequency boost mode’ (3.6GHz) to deliver audio/video with acceptable latency and lag(between AV). The 2.4GHz model, not able to use
higher clocks, just can’t keep up with processing whatever your SDK is doing.
We are using a win10 client on one side, and your WebSDK 1.7.0, running inside chrome version 78 on the other side. Please also note that no other cpu-demanding taks are run on the SDK host.
The problem seems to be one thread inside chrome thwarting your whole application. On the 2.4GHz model, this single thread is occupying one core for its own, and still not able to finish his work(encoding?) on-time s.t. audio/video is fluid and not laggy.
Its remarkable that running the in-browser application on the 2.4GHz platform works quite well, i.e. much better than running the SDK.
-
Therefore i am wondering where this performance difference between SDK and in-browser client comes from, and if you are planning to migrate the SDK implementation to a similar on as used in-browser.
-
As our tests also have shown that this SDK performance problems are related to the available bandwidth (via the SDK chosen resolution / framerate?) i would like to ask what ‘low bandwidth’ scenarios your SDK client should be used for? How is this bandwidth measured, and can this be used somehow to obtain smaller resolutions or framerates, resulting in acceptable AV latency + lag?
-
Do you already have a release date for SDK 1.8? Which features / improvements will be implemented?
Thx again!
Hari