Re: [mediacapture-region] Is muting track the right call for empty cropped tracks (#9)

> > I'd be happy to drop everything mute-related from the spec
> 
> Sounds good.

To clarify, I'll be removing references to `mute`, but otherwise the behavior will remain the same - no new frames will be delivered if the application specified a crop and either (i) it's not possible to crop to that element, e.g. if it's gone, or (ii) cropping to that element results in zero pixel frames, e.g. if the crop-target has been scrolled out of the viewport.

> It seems worth opening a new issue to keep track of this area

I think we can keep using this issue and continue the discussion here? I've applied the label `Improvement` to make it clear that we've agreed this is a non-blocking issue.

Continuing the discussion - there are multiple cases where the application either cannot recognize what's going on, or it's not ergonomic for it to do so, or it would introduce a delay due to cross-origin communication to achieve. That's why I used the `mute` signal. If `mute` is problematic because it's hard to tell apart from existing uses, we can introduce a similar signal (maybe `interrupted`) if we find out developers are asking for it. IMHO it's fine to start by using the same signal for all interruption reasons.

Another option, and one which I like better, is to **keep** using `muted`, `onmute` and `onunmute`, but to add a `mute_causes` vector:

```webidl
enum MuteCasue {
  "user",
  "target_lost",
  "zero_pixel_frame"
};

partial interface MediaStreamTrack {
  readonly sequence<MuteCasue> mute_causes;
}
```


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 26 January 2022 15:53:24 UTC