Intent to Experiment: Region Capture

[Elad Alon]

Contact emails

elad...@chromium.org, mfo...@chromium.org, jop...@chromium.org

Explainer

https://github.com/eladalon1983/region-capture/blob/main/README.md

Specification

https://eladalon1983.github.io/region-capture/

Summary

Recall that applications may currently obtain a capture of the tab in which they run using getDisplayMedia, either with or without preferCurrentTab. Moreover, soon another API will allow similar functionality - getViewportMedia. In either case, the application may then also wish to crop the resulting video track so as to remove some content from it (typically before sharing it remotely). We introduce a performant and robust API for cropping a self-capture video track.

Blink component

Blink

TAG review

Pending

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Ergonomics

N/A

Activation

Should be relatively unchallenging to use.

Security

This is a mechanism by which an application purposefully strips away information which it already has access to (via pre-existing mechanisms such as getDisplayMedia).

Goals for experimentation

Evaluate the usefulness of the feature and gather Web-developer feedback about how it may improve.

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

Supported on all desktop platforms, but not on mobile platforms, as the prerequisite API of getDisplayMedia is currently only available on desktop.

Is this feature fully tested by web-platform-tests?

No

Flag name

RegionCapture

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1247761

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1168076

Estimated milestones

OriginTrial desktop last	97
OriginTrial desktop first	97

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5712447794053120

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/dib14W1B0Xc

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Do I understand correctly and you want to experiment for a single milestone? (M97)

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDPGYJBWv6xTaRPPAkCtCCU5RRhskk459kY4yhhsZtTSdg%40mail.gmail.com.

[Elad Alon]

Thanks for catching that typo. The corrected request is m97 - m100.

[Yoav Weiss]

LGTM to experiment M97-M100 (inclusive)

On Thu, Oct 7, 2021 at 10:34 AM Elad Alon <elad...@google.com> wrote:

Thanks for catching that typo. The corrected request is m97 - m100.

On Thu, Oct 7, 2021 at 9:20 AM Yoav Weiss <yoav...@chromium.org> wrote:

Do I understand correctly and you want to experiment for a single milestone? (M97)

On Tue, Oct 5, 2021 at 11:12 PM 'Elad Alon' via blink-dev <blin...@chromium.org> wrote:

Contact emails

elad...@chromium.org, mfo...@chromium.org, jop...@chromium.org

Explainer

https://github.com/eladalon1983/region-capture/blob/main/README.md

When looking at the API, I found that it's unclear why a cropID is needed (compared to using an element ID instead, or just passing the element to `cropTo`). Would be good to further explain that.

 

Specification

https://eladalon1983.github.io/region-capture/

May be good to try and move the spec over to the WICG. I saw activity on the related proposal, so it may be good to get explicit support from folks that'd enable such a move.

 

Summary

Recall that applications may currently obtain a capture of the tab in which they run using getDisplayMedia, either with or without preferCurrentTab. Moreover, soon another API will allow similar functionality - getViewportMedia. In either case, the application may then also wish to crop the resulting video track so as to remove some content from it (typically before sharing it remotely). We introduce a performant and robust API for cropping a self-capture video track.

Blink component

Blink

TAG review

Pending

Plans to file for a TAG review?

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Can you file for https://bit.ly/blink-signals?

[Elad Alon]

When looking at the API, I found that it's unclear why a cropID is needed (compared to using an element ID instead, or just passing the element to `cropTo`). Would be good to further explain that.

Will  do along with my next pass over the spec and README, which I intend to do after we're done coding the MVP.

May be good to try and move the spec over to the WICG. I saw activity on the related proposal, so it may be good to get explicit support from folks that'd enable such a move.

I am scheduled to present about this feature on the WebRTC Working Group interim in November. After that, and after we have the MVP landed, I intend to step up my partner-seeking efforts.

 

Plans to file for a TAG review?

Definitely, but I want to have a first do a first pass in the WebRTC  Working Group and have the MVP landed and exposed to OT.

Can you file for https://bit.ly/blink-signals?

I intend to do so after I've had time to present to Apple and Mozilla in the aforementioned interim.

[Elad Alon]

Hi Yoav. Could the origin-trial period please be amended to m98-m101 (inclusive), as we've landed a CL blocking this from OT in m97.

[Yoav Weiss]

LGTM for M98-M101