Closed hunnorth closed 10 months ago
Thank you for the development work. We have also encountered a similar issue in our service, as described by hunnorth.
Furthermore, we have verified that the problem is resolved when launching the demo application on the "video-ml/release" branch.
Could you please provide an estimate for when this release is expected? We would greatly appreciate it if you could release it as soon as possible.
@kenpp unfortunately even after this is merged it may be until December until we do another release. ~On a related note, I and others are no longer able to reproduce the original issue, but not sure why. Is it still reproducible on your machine?~ Turns out tab throttling is selectively enabled. With current version of chrome it will not start throttling if audio playback (i.e. speakers) are enabled.
Description of changes: Frames per second of video stream was being processed on the main thread using setTimeout. However, when a meeting window gets moved into the background, the main thread timer used in setTimeout gets throttled and the fps drops dramatically. To overcome this issue, this PR will move the setTimeout call into a worker thread that does not get throttled.
Testing:
Can these tested using a demo application? Please provide reproducible step-by-step instructions. Yes, start a meeting with at least one other attendee. Enable a video filtered and then hide the window (switch tabs). The other attendee should then observe no fps degradation in filter-enabled attendee.
Checklist:
Have you successfully run
npm run build:release
locally? yesDo you add, modify, or delete public API definitions? If yes, has that been reviewed and approved? no
Do you change the wire protocol, e.g. the request method? If yes, has that been reviewed and approved? no
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.