W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2022

Re: [mediacapture-region] Is BrowserCaptureMediaStreamTrack needed? (#10)

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Tue, 25 Jan 2022 19:29:00 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1021533664-1643138938-sysbot+gh@w3.org>
`BrowserCaptureMediaStreamTrack` was **not** introduced because of cloning. True, I have attached some mandates to `BrowserCaptureMediaStreamTrack.clone()`. But it's possible to put those elsewhere. Rather, the reason was...

[DisplayCaptureSurfaceType](https://w3c.github.io/mediacapture-screen-share/#displaycapturesurfacetype) exposes whether the user shared a tab, but not **which** tab, and definitely not whether it's the current tab. BCMST allows us to expose `cropTo()` only on such tracks where it is (potentially) valid to call.

There are alternatives:
* Expose `cropTo` more widely and expect applications to call it "optimistically" and be robust to failure.
* Rely on the yet-unadopted [Capture Handle](https://wicg.github.io/capture-handle/) (shameless plug, cough-cough...).
* OCR-like hacks.

But exposing a control only where it is (potentially) valid seems to me like the most elegant, self-contained approach.

If we find in the future that we want to expose `cropTo()` on additional surfaces, there'll be nothing stopping us. But I don't expect that this is coming too soon. Other tabs - yes. But windows and screens - not with the current CropTarget. So arguably window/screen-cropping would be entirely separate APIs.

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/10#issuecomment-1021533664 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 25 January 2022 19:29:02 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:55 UTC