[mediacapture-main] Avoid circular definition of muted. (#982)

jan-ivar has just created a new issue for https://github.com/w3c/mediacapture-main:

== Avoid circular definition of muted. ==
This [definition](https://w3c.github.io/mediacapture-main/#track-muted) is backwards: _"If live samples are not made available to the MediaStreamTrack it is **muted**"_.

Mute causes lack of frames, not the other way around: If a MediaStreamTrack is **muted**, no live samples are made available it.

All subsequent language and examples align with **muted** being an _intentional User Agent initiated change_:

<img width="832" alt="image" src="https://github.com/w3c/mediacapture-main/assets/3136226/a58be928-dd9c-4190-a82b-9a9bc0e33e51">

Crucially, the _"change" of state_ (not just the event) is _initiated_ by the User Agent.

This has caused confusion in implementations. E.g. @youennf replied in https://github.com/w3c/mediacapture-extensions/issues/39#issuecomment-1824119912:
> Thanks @guidou, this is really helpful info.
> 
> > For camera tracks, Chrome just checks if frames have not been received for some time (25 expected frame intervals in most cases), regardless of the underlying reason. This maps well to the spec text that states [If live samples are not made available to the MediaStreamTrack it is muted](https://w3c.github.io/mediacapture-main/#track-muted),
> 
> The spec allows it. I wonder though whether this model is actually helping web developers. For instance, is it better to have a black video or a frozen video when the track is sent via WebRTC?

In general, the value of an "event" is its intent, that something external happened. Therefore, synthesizing events reactively from symptoms seems a mistake. For example: [crbug 941740](https://crbug.com/941740) implements mute on remote tracks reactively based on (lack of) input, violating the WebRTC spec and causing web compat issues. Doing the same on capture tracks seems like a bug, and should be a violation of this spec, but is attributed to the aforementioned line in the spec.

> The stats API that @henbos is working on could be more appropriate for web developers.
> 
> FWIW, in Safari, if we do not receive video frames/audio frames after a given amount of time, we fail the capture.
We assume that something is wrong and that the web application be better restarting capture, maybe with a different device. Some web applications do this, not all of them sadly.
> 
> These browser differences are making developer's life difficult. I wonder whether this space is now mature enough that we could get browsers to share a more consistent model around muted and capture suspension/failure.
@jan-ivar, how is Firefox using muted these days for capture tracks? Is Firefox sometimes failing capture?

Firefox fires `mute` as explained in the OP of https://github.com/w3c/mediacapture-extensions/issues/39#issue-1037935336 (behind a pref) but never reactively from symptoms. 

### Proposal:

Replace the confusing sentence with _"If a MediaStreamTrack is muted, no live samples are made available it."_

Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/982 using your GitHub account


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

Received on Wednesday, 6 December 2023 21:21:09 UTC