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: Thu, 27 Jan 2022 09:52:05 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1023031143-1643277124-sysbot+gh@w3.org>
> I am not sure to follow, either BrowserCaptureMediaStreamTrack is for any tab capture or for self tab capture only.
Can you clarify? My understanding is that this is the former.

Sorry, I got myself mixed up there. Not sure what I was thinking. Your point about [DisplayCaptureSurfaceType ](https://w3c.github.io/mediacapture-screen-share/#displaycapturesurfacetype) was valid.

My objection remains that it would be odd to expose `cropTo` on irrelevant streams. Mostly audio, but also just plain-old video with a different surface type. I think it would be useful to move towards having different subclasses for audio/video, etc.

Your example of crop-monitor-track-to-focused-window is interesting and I'd love for it to be added one day, but I don't think we can assume it will use cropTo (might end up with a different API depending on how the discussion progresses). Even if we **do** overload cropTo for that, I think it will make more sense to expose:
* A cropTo() that accepts CropTarget on tab-capture-video-tracks.
* A cropTo() that accepts something-else on monitor-capture-tracks.
* No version of cropTo() anywhere else. (Including audio.)

At any rate, I think it will be easier to expose more widely later, than to reduce exposure later.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 27 January 2022 09:52:07 UTC

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