- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Jan 2021 18:23:47 +0000
- To: public-webrtc-logs@w3.org
> I filed w3c/mediacapture-extensions#16 so that we do not hijack this thread. @youennf Thanks, I've commented on transferring MediaStreamTrack there. > Transmitting a video to a conference may involve a significant amount of application logic - especially with some upcoming/under-discussion features such as Breakout Box, Web Codecs, Insertable Streams, Lego Laser, etc. Why, are you planning to blur the desktop? Or add overlays? Serious question, because, if you are, such app logic may belong more naturally in the top-level page, which actually owns, knows and controls what's being captured, than the sub-iframe. Complexity arguments are double-edged swords: A complexity sufficient to scare away web developers from using browser features directly would count against standardizing such APIs in my book. I'd also keep in mind they're not standard (yet). Demand for lower-level APIs presumably comes from developers who want this level of access to do work, and it's our job to make those APIs as simple and easy to use as possible. If sites decide to do this through JS libraries, hopefully, such libraries can easily be pulled into the top-level page as well, which is the one in charge of the merged experience. > I don't think large applications like Slides/Docs, that normally do not handle any video-conferencing, should be expected to take on that responsibility. I'd like to push back on this. I actually think they do. The original premise that a slides app beams itself into a web conference, suggested to me that the natural separation of concerns was for the slides app to own that part. This is the crux of better integrated HTML capture to me. As features grow, things like remote interaction with the content (remote mouse pointers etc.) all seem more naturally handled by the app that's capturing "itself". As a corollary, if video-capture of DOM weren't available the "full web" approach to enable a remote HTML experience, might be to recreate the DOM using existing web. That would definitely fall into the scope of the slides app, and would be significantly more work than video capture. The alternative where one origin spies on another, which seems like a part of `getDisplayMedia` we should refrain from building on, or at least not encourage. A counter-argument perhaps might be needing to show a "self-view" of the capture, like WebEx does this, except where would one expect the self-view to appear? In slides or in the meet iframe? As described, the main app here seems like slides, and whether we postMessage instructions or the results of said instructions seems like a detail. Last, but not least, for this feature to be safe, it needs to be secured by something like COEP, as I propose in https://github.com/w3c/mediacapture-screen-share/issues/155. Those restrictions would need to apply to the top-level page, so we might as well assume it will need to be deeply involved. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/158#issuecomment-768481272 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 January 2021 18:23:49 UTC