- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Jan 2022 09:52:05 +0000
- To: public-webrtc-logs@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