- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Nov 2024 18:24:06 +0000
- To: public-webrtc-logs@w3.org
> Is the requirement the same for these? I would think so. Pausing the video element, pausing the MediaRecorder, setting `track.enabled = false` for RTCRtpSender should all prevent new frames from being displayed/recorded. No need for asynchronicity here. Asynchronicity is needed for MediaStreamTrackProcessor with a CaptureController callback. There is no such requirement if the notification happens at the track level. > But the workarounds web developers would need to use on the regular seem borderline unreasonable `track.enabled = false` is probably the straightforward solution to prevent exposing new frames too soon. It should work out of the box for all sinks without requiring asynchronicity. Do we agree on this? If you want to freeze instead of mute, there are solutions as illustrated above, some of which are only a few lines of code. > pausing where the switch happens seems inherently simpler for web developers MSTP is one example that shows that notification at the track level is actually simpler. Also, `pauseOnSurfaceSwitching` could start as a boolean and be changed to a callback returning a promise if we get a need for asynchronicity. In any case, `configurationchange` should fire in case of surface switch and will provide the web application potentially useful information for handling surface switch (type & ID of surface for instance). -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/15#issuecomment-2452368295 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 1 November 2024 18:24:08 UTC