- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 Jan 2025 18:57:09 +0000
- To: public-webrtc-logs@w3.org
> For example, `stop()` and `enabled` are synchronous. Blocking the main thread to provide the same semantics while messaging across threads can have a nontrivial cost in terms of user-perceived performance. Event handlers and `mute` probably also have their own set of issues. Can you elaborate what the actual issues are? I can understand the general idea but not the practical implications. In particular, the source is off the main thread and all control surfaces basically need to hop to the source thread. At worse, the shim would add a slight delay by hopping to the worker thread and then to the source thread. I don't think the main thread should be blocked to emulate `stop()` or `enabled`. In the case of a track -> track transform, I would expect applications to `stop()` the transformed track, the worker gets notified in VideoTrackGenerator, which will stop the worker track. No issue AFAIUI. Ditto for `enabled`, I would expect it to happen on the transformed track (and maybe on the source track as an optimization?). I could see an extension to VideoTrackGenerator so that it gets notified that all the tracks related to it have `enabled = false` like native sources have as a way to optimise processing (stop sending video frames that no sink is interested in). -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2583604191 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 10 January 2025 18:57:10 UTC