How quickly and widely getViewportMedia() is adopted depends in large part on the adoption of cross-origin isolation by Web developers. Once cross-origin isolation enjoys wide adoption, I see no blockers to deprecating EC-over-gDM in favor of EC-over-gVM.
On Monday, November 11, 2024 at 7:49:04 PM UTC+1 dan...@microsoft.com wrote: > Do you have a rough idea of how long do we expect to be in this > intermediate state where Element Capture is available with > getDisplayMedia() rather than getViewportMedia()? Presumably the longer > that lasts the harder it will be to remove the getDisplayMedia() way of > doing it once getViewPortMedia() is available. > > > > -- Dan > > > > *From:* 'Elad Alon' via blink-dev <blin...@chromium.org> > *Sent:* Monday, November 11, 2024 1:22 AM > *To:* blink-dev <blin...@chromium.org> > *Subject:* [EXTERNAL] [blink-dev] Intent to Ship: Element Capture > > > Contact emails > > elad...@chromium.org > > > Explainer > > https://github.com/screen-share/element-capture/blob/main/README.md > > > Specification > > https://screen-share.github.io/element-capture > > > Summary > > API for capturing a subtree of the DOM. > > > > Given a video MediaStreamTrack obtained through pre-existing means to > initiate tab-capture, Element Capture allows mutating the track to only > capture a subtree of the DOM starting at a given Element. > > > > The API bears some resemblance to the Region Capture API, but affords > greater flexibility for applications, because occluding and occluded > content are both excluded from the capture. > > > Blink component > > Blink>GetDisplayMedia > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EGetDisplayMedia> > > > TAG review > > https://github.com/w3ctag/design-reviews/issues/954 > > > TAG review status > > Issues addressed > > > Chromium Trial Name > > ElementCapture > > > Origin Trial documentation link > > https://github.com/screen-share/element-capture/blob/main/README.md > > > WebFeature UseCounter name > > kElementCapture > > > Risks > > > Interoperability and Compatibility > 1. Other browser vendors have not indicated an intention to implement and > ship this feature; however, we are working with them to ensure that our own > implementation would most closely align with their own vision; see details > in “Anticipated spec changes” below. 2. There is no compatibility risk > because this is a completely new feature. > > > > *Gecko*: > > https://github.com/mozilla/standards-positions/issues/857 > > Currently marked as negative, but discussions in the joint SCCG – WebRTC > WG meeting during TPAC 2024 (minutes > <https://github.com/screen-share/meetings/blob/main/minutes/2024-09-24%20(TPAC%202024%2C%20joint%20with%20WebRTC%20WG).md#element-capture-elad-alon>), > > indicate that Mozilla’s position is likely to change if we only allow > track.restrictTo() on tracks derived by getViewportMedia(). We intend to > adopt this restriction once getViewportMedia() is shipped. Mozilla has been > formally > asked > <https://github.com/mozilla/standards-positions/issues/857#issuecomment-2405872931> > > whether this would change their position; no response yet given. > > > > *WebKit*: > > No signal > > https://github.com/WebKit/standards-positions/issues/280 > > > > *Web developers*: *Strongly positive* > > *LibreStream* > > · Source > <https://www.w3.org/community/sccg/2024/02/08/element-capture-origin-trial-starting-m121/> > > · “This is perfect. We have a video collaboration app where we need > to share documents (e.g. PDFs) so users can walk through the document > together. As part of this, we have a document viewer that the sharer needs > to share dur-ing the call and scroll through different pages where others > can annotate on the shared document. Prior to Element Capture, this was a > lousy user experience since the entire window needed to be displayed and > didn’t allow annotations from the sharer. Thank you!” > > > > *Engagely* > > · Source > <https://github.com/screen-share/element-capture/issues/3#issuecomment-2119105313> > > · “I highly support adopting this specification. We at Engageli > intend to use it for our session recorder, and for collaboration tools.” > > > > *Tango* > > · Source > <https://github.com/screen-share/element-capture/issues/3#issuecomment-1483660309> > > · “I can't emphasize enough how instrumental this specification > would be for our product and user experience.” > > > > *RGO Communications* > > · Source > <https://github.com/screen-share/element-capture/issues/58#issue-2636463347> > > · “We support this API. We have not participated in the origin > trial due to prioritization issues; however, we intend to use the API after > it's shipped.” > > > > *AudioPump* > > · Source > <https://github.com/screen-share/element-capture/issues/58#issuecomment-2458176856> > > · “At AudioPump, Inc., we have several projects that use similar > APIs and will likely also implement Element Capture. There are no specific > plans at the moment, and the current restrictions cut down on the use > cases, but I'm sure once it becomes available for users, we will implement > something.” > > > > *Tella* > > · Source > <https://github.com/screen-share/element-capture/issues/3#issuecomment-1484858622> > > · “I support adopting the Element Capture specification. We could > in the future use this to do cleaner screen captures in our chrome > extension. We'd let the user "inspect" the page and pick the part they'd > want to capture more specifically.” > > > > *Mux* > > · Source > <https://github.com/screen-share/element-capture/issues/3#issuecomment-1484886738> > > · “I support adopting the Element Capture specification.“ > > > > *Zoom* > > · Source > <https://github.com/screen-share/element-capture/issues/3#issuecomment-1486716646> > > · “Element capture has its use case. it is different as region > capture. Up for it.“ > > > > *Dialpad* > > · Source > <https://github.com/screen-share/element-capture/issues/3#issuecomment-1509622596> > > · “I support adopting the Element Capture specification.” > > > > *Chromatic* > > · Source > <https://github.com/WICG/proposals/issues/73#issuecomment-1285112981> > > · “It could also help for tools like https://www.chromatic.com/ for > visual regression testing!” > > > > *Storitto + Audiocado* > > · Source > <https://github.com/WICG/proposals/issues/73#issuecomment-1285298922> > > · “We use the browser to create videos for Storrito.com and > Audiocado.com, the described feature would have saved me many headaches.” > > > > *Remotion* > > · Source > <https://github.com/WICG/proposals/issues/73#issuecomment-1286827842> > > · “I am also very interested in this API and second that it will be > important to get the frame in an uncompressed way. For Remotion, we will be > able to provide in-browser video rendering if this API ships and generally, > this would open the door for web-based offline video editors to become more > powerful (the status quo is that only canvas-based graphics can be exported > as images).“ > > > Debuggability > > No changes to DevTools are intended. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? > > No > > This API is supported on all desktop platforms. Mobile platforms are > unsupported because screen-capture itself is unsupported on those platforms. > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > Yes > > > Flag name on about://flags > > element-capture > > > Finch feature name > > ElementCapture > > > Tracking bug > > https://bugs.chromium.org/p/chromium/issues/detail?id=1418194 > > > Launch bug > > https://launch.corp.google.com/launch/4240472 > > > Sample links > > https://element-capture-demo.glitch.me > > > Estimated milestones > > Shipping on desktop > > 132 > > Origin trial desktop first > > 127 > > Origin trial desktop last > > 132 > > > Anticipated spec changes > > At the moment, Chromium’s implementation of Element Capture works with > `getDisplayMedia({preferCurrentTab > <https://wicg.github.io/prefer-current-tab/>: true})`, which is > Chromium’s temporary stopgap for getViewportMedia() > <https://w3c.github.io/mediacapture-viewport/>. In the future, after > getViewportMedia() is fully specified, implemented and gains wide adoption, > we will limit Element Capture to only work with tracks derived from > getViewportMedia() calls, and deprecate the ability to call restrictTo() on > tracks obtained with anything other than getViewportMedia(). > > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5198989277790208?gate=5129718719840256 > > > Links to previous Intent discussions > > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDO6y5b6y3q9QEd2scsYPWuWLJBnPLgwm%2BaHpKx36CYMwA%40mail.gmail.com > > Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDN8mcO%2BYqaVA5nb5BBv-dZB0wqwfh9580wMc-e%2BNuP7yw%40mail.gmail.com > > > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDPwMu%3D0_RCdRKrwa-w5Egj29priVsB%3DJwgXOby2QKkrQQ%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDPwMu%3D0_RCdRKrwa-w5Egj29priVsB%3DJwgXOby2QKkrQQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d85a8a96-a5ca-4c99-ad91-0de9a07c3baen%40chromium.org.
