- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Sep 2020 14:15:18 +0000
- To: public-webrtc-logs@w3.org
This issue https://github.com/w3c/mediacapture-screen-share/issues/105 was closed by https://github.com/w3c/mediacapture-screen-share/issues/105#issuecomment-521667012 > This seems to be possible to do with current APIs, so no compelling reason seen for more browser surface. where, if considered applicable at Screen Share, the same appears to be applicable here. That is, get the original captured image, manipulate the image any way you want to, use the manipulated image as source for the video expected to be created. Otherwise we place a great amount of responsibility on implementations to effectively edit videos in real-time, where, so far the empirical evidence is that Chromium still captures the prompt they have developed which can contain screens, applications, monitors not intended to be captured in the first 7 seconds of the capture. So, no matter if the correct constraints are applied, it is still possible to get user data not intended to be exposed, and capture a prompt that could very well be meaningless to the stream intended to be created, by overlaying the actual screen intended to be captured. Now, you have already merged the PR to fix that. Yet Chromium evidently ignored the memo. Thus, why would users - and the authors of this specification - trust implementations to precisely apply constraints, consistently? -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/729#issuecomment-700035287 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 September 2020 14:15:19 UTC