- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Nov 2024 19:23:14 +0000
- To: public-webrtc-logs@w3.org
> 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. If we allowed `transceiver.sender.track = null` we could pause the last one too! (we could make it throw on non-null) > If you want to freeze instead of mute, there are solutions as illustrated above, some of which are only a few lines of code. There's a dependency here on https://github.com/w3c/webrtc-pc/issues/3014. > 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). There's a dependency here on (a new issue that needs to be filed following) https://github.com/w3c/mediacapture-screen-share/issues/306. > Also, pauseOnSurfaceSwitching could start as a boolean and be changed to a callback returning a promise if we get a need for asynchronicity. That might work. -- 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-2452459484 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 19:23:15 UTC