- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Jan 2022 19:29:00 +0000
- To: public-webrtc-logs@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