- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Jun 2024 18:28:11 +0000
- To: public-webrtc-logs@w3.org
The capture handle is indeed reset, and you'll get no capture handle until the refreshed page loads to the point where it sets it again. I don't think we can avoid this atm, because we don't really know if the captured page will ever call setCaptureHandleConfig() again. But I believe you have a work-around available: * Upon observing the change of capture handle from a permitted origin to null, pause remote transmission of the video. * Hold off on any user-facing messaging for a few seconds. * If the refreshed page ends up setting the permitted origin - great, it's a refresh and you can resume remote transmission of the stream. * Otherwise, display some message to the user. It's an imperfect solution - it will delay messages when they're needed, and occasionally it will show messages right before the page loads far enough to set the capure handle - but that's what you can do with existing APIs. If you try this out, I would love to hear the empirical evidence of how well it worked. Btw, you might be concerned that not all frames will be supressed, because the event might fire and be handled after some disallowed frames are captured and transmitted remotely. I had filed [this proposal](https://github.com/w3c/mediacapture-screen-share-extensions/issues/4) for it in the past. Since then, @tovepet has taken over this endeavor. I bet she'd love to get in touch with you and see if the solution she's working on could address your use case as well. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/74#issuecomment-2159028761 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 June 2024 18:28:12 UTC