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

> 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 to it.
> 
> All subsequent language and examples align with **muted** being an _intentional User Agent initiated change_:
> 
Not all subsequent language  align with **muted** being an _intentional User Agent initiated change_. In fact, I would argue that no language at all aligns with this. The word _intentional_ does not appear anywhere in the spec.
The list you refer to is presented as situations that "can be" reason to mute a track. Nowhere is it stated that any element in that list is actually a reason to mute, or even that it SHOULD cause mute. At best, it can be interpreted as a MAY.
More importantly, [Section 4.3.1.1 of the spec](https://w3c.github.io/mediacapture-main/#life-cycle) says:

**_The muted/unmuted state of a track reflects whether the source provides any media at this moment._**

**_A [MediaStreamTrack](https://w3c.github.io/mediacapture-main/#dom-mediastreamtrack) is [muted](https://w3c.github.io/mediacapture-main/#track-muted) when the source is temporarily unable to provide the track with data_**

And [Section 8](https://w3c.github.io/mediacapture-main/#event-summary) says the **mute** event is fired when **_The MediaStreamTrack object's source is temporarily unable to provide data_**, and the **unmute** event is fired when **_A MediaStreamTrack has been removed from this stream. Note that this event is not fired when the script directly modifies the tracks of a MediaStream._**

This makes it clear that the model is that muted means no media from the source to the track, and disabled means no data from the track to its consumers.
 
> In general, the value of an "event" is its intent, that something external happened. Therefore, synthesizing events reactively from symptoms seems a mistake. 

Maybe it was a mistake that the spec defined the muted attribute and the corresponding events the way it did years ago. But, mistaken or not, that's how it was defined.

> 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. 

In this case, Chromium just is applying the model defined in the main spec to remote tracks. The WebRTC spec indicates some cases in which the muted attribute should be set/unset, but AFAICT it does not say anywhere that this overrides the model defined in the original MediaStreamTrack specification. It also does not state a new definition of *muted* specific for WebRTC tracks and does not even list the muted/unmuted events in its [Event Summary section]. 

Shouldn't specs that override/redefine concepts inherited from other specs explicitly state it?.  Until we make this more explicit in the WebRTC spec, my position is that https://crbug.com/941740 is not a spec-compliance bug in Chromium. If anything, it looks more like a spec bug in the WebRTC spec. 

> Doing the same on capture tracks seems like a bug, 
Are you saying it seems like a spec bug or a Chromium bug? 
It is pretty clear to me that Chromium behavior is spec compliant.

> and should be a violation of this spec,
Are you saying Chromium behavior is in violation of the spec, or that the spec should be rewritten such that Chromium behavior becomes a violation of the spec? 

>  but is attributed to the aforementioned line in the spec.
Not only that line. As I showed, the concept of muted meaning no data from source to track is in many places in the spec, and is the only way **muted** is defined. 

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

Maybe Firefox's behavior is the one in violation of the spec?

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

Can you clarify what this sentence means?
Is it a description of something that happens when a track is muted? In that case it's not a definition and it's not that different from the original, except in that it is not longer a definition.
Basically, it replaces "A is defined to be B" with "A implies B". 

Or is it a statement that if the UA detects a condition that should mute the track, then it should make sure the track does not receive any media? 

Either way, the change is not enough, since the concept of **muted** meaning no data from source to track is in many other places of the spec.

Finally, I am opposed to an incompatible redefinition of the meaning of **muted** because experience shows that this type of change is difficult to deploy in practice and can lead to more interoperability issues.

I am not opposed to a redefinition that provides a path for existing applications to use a newer, more useful definition, without making it impossible for applications to continue relying on the old definition.


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/982#issuecomment-1853733588 using your GitHub account


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

Received on Wednesday, 13 December 2023 11:21:26 UTC