- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Mar 2022 11:04:20 +0000
- To: public-webrtc-logs@w3.org
Do we even need to specify behavior of track muted state in this spec? My initial impression is that here we should just specify that a muted generator does not produce any frames. Track muted state and generator muted state are two different things. The language in mediacapture-main should take care of the track muted state. Some text from mediacapture-main for reference: > 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. > A track can be muted by a user. Often this action is outside the control of the application. > A track can also be muted by the [User Agent](https://w3c.github.io/mediacapture-main/#dfn-user-agent). I don't see it as a necessity that muting a generator should synchronously mute all connected tracks. The UA can detect this and mute the tracks using any logic it wants (asynchronously if it so prefers). I do see it as a problem that unmuting a generator should force-unmute all connected tracks, because that could be in conflict with the UA judging that it should remain muted (e.g., due to user action via UI or some other UA-specific mechanism). -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/81#issuecomment-1056797234 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 March 2022 11:04:22 UTC