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

Re: [mediacapture-region] Can the MediaStreamTrack list its cropping regions directly? (#6)

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Wed, 19 Jan 2022 19:44:08 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1016808630-1642621446-sysbot+gh@w3.org>
I generally like the idea, but I see some issues. Discussion follows.

> The main issue with that idea is that this might require to expose an API on the capturee-side, so that the MediaStreamTrack source can explicitly list its regions.

Not necessarily. We could say that calling [produceCropTarget()](https://w3c.github.io/mediacapture-region/#producecroptarget-method) immediately registers the crop-ID on all relevant tracks, present and future.

> ```
> interface MediaStreamTrackRegion {
>     USVString origin;
>     DOMString name;
> }
> partial interface MediaStreamTrack {
>     readonly attribute sequence<MediaStreamTrackRegion> regions;
> ```

As mentioned, I like the idea. Some potential issues here, curious to hear if you have good solutions.

1. There's no guarantee that `name` is unique, even within a given origin (consider same-origin iframes that are unaware of each other). In such a case, it'd still be necessary for the entity minting crop-IDs/TabRgions to communicate them directly to would-be collaborators. (Consider multiple non-collaborating iframes each declaring "main".) If that is indeed necessary, perhaps the effort of exposing regions on the track would be fruitless. Wdyt?
2. Although I don't atm think it's a real issue, it bears mentioning that this design means that whoever mints a token, has to keep in mind that this is a "loud" and public action, that can be "heard" by unexpected entities, if they happen to be allowed to call gDM (and if the user approves the capture).

> partial navigator MediaDevices {
>    readonly attribute regions;

nit: I think you mean `readonly attribute MediaDevicesTabRegions regions`. Please let me know otherwise.

> This might be getting more complex if transferring the MediaStreamTrack say to a worker.

Not sure if "complex" is the right word, but it's a bit more ergonomic if tokens are already attached to the track, than if the sender has to "manually" attach them to the message (or send a separate message). Modulo aforementioned issues. I do not see this as a strong selling point.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 January 2022 19:44:10 UTC

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