- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 08 Nov 2024 19:20:06 +0000
- To: public-webrtc-logs@w3.org
> ... I believe that it would be easier for applications to be notified by the CaptureController and to allow them to pause the capture at the source level. I can get behind this, if by "pause" you mean halting frame delivery rather than mute. Frame delivery is a property of the source today, so keeping a "pause" concept entirely contained there, and distinct from today's track states seems clean and appealing to me. > We could model this on VideoTrackGenerator.muted, which I believe have the behavior we seek: `VideoTrackGenerator.muted` is different. It controls the muted state (firing `mute` and `unmute` events) on downstream tracks, and produces black frames. It gives JS backdoor-control over events that otherwise go unused. That seems wrong here. Muted is [not unused](https://w3c.github.io/mediacapture-screen-share/#hidden-display-surfaces) in screen capture. This could work: ```js controller.surfaceSwitchingCallback = () => { controller.paused = true; setup().then(controller.paused = false); }); ``` It would would NOT fire muted. @tovepet is that still close to what you proposed? My feedback then is that subtle details might be unobvious with this API: - frame delivery is on a background thread, so UAs would still need to pause *before* calling this callback, and only unpause if the `paused` state is false synchronously afterwards. - The API allows randomly pausing at other times, overshooting the use case for no clear reason Therefore, I think I'd still prefer the promise version which doesn't have these problems or subtleties: ```js controller.surfaceSwitchingCallback = async () => { await setup(); }); ``` -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/15#issuecomment-2465582949 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 8 November 2024 19:20:07 UTC