- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Sep 2018 23:01:12 +0000
- To: public-webrtc-logs@w3.org
I looked at the getUserMedia UI currently being implemented: - Safari has a UI to mute/unmute capture on a given tab. Video becomes black if muted and relevant mute/unmute events are fired. - Firefox has a UI to revoke access for a capturing page. Video freezes and an ended event is sent. - Chrome has a UI to permanently revoke access for a capturing site. This has no effect on the current page. The distinction between mute and ended also makes sense in getDisplayMedia: - A UI disables permanently an ongoing screen capture, a window is closed: ended events make sense. - A UI allows disabling temporarily screen capture: mute/unmute events make sense. Window minimization fits nicely in the temporarily disabled bucket: muted events are probably easier to handle by web apps than a 0x0 video stream. Locked screens fit also well there, especially if the captured display type is not screen. A UA might also decide to end a track based on some heuristics (amount of time being muted, locked screen...). I haven't looked precisely at the disconnected screen case but I think it could fit in both buckets. The screen capture spec could refer to https://w3c.github.io/mediacapture-main/#life-cycle-and-media-flow and provide some informative guidance, for instance: - Mute a track in reversible conditions. Mention window minimization, locked screen or no way to indicate ongoing capture - End a track in case of non reversible conditions. Mention: window/application gets closed -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/72#issuecomment-420089189 using your GitHub account
Received on Monday, 10 September 2018 23:01:21 UTC