W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2013

Re: live, muted, enabled, and ready-state

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 22 Mar 2013 14:42:51 +0100
Message-ID: <514C5FDB.5030900@ericsson.com>
To: public-media-capture@w3.org
On 3/22/13 2:17 PM, Cullen Jennings (fluffy) wrote:
>
> The draft is confusing to readers on the topic of what these all
> mean. Later in the email I will provide what meaning I can extract
> from the draft but first let me propose my suggestion to clean up
> this mess.
>
> 1) remove the enabled attribute, you can get all the info from the
> readyState, or if you really want to keep this attribute, rename it
> to muted
>
> 2) add a method to mute/unmute. Give some thought to if this needs to
> be asynchronous or not
>
> 2) In the MediaStreamTrackState enum, change the name of "live" to
> "unmated".
>
> 3) everywhere in the specification get rid of the word enable and
> live and replace them with muted / unmated concept

There is a difference between "enabled/disabled" and "muted/unmuted". 
Enable/disable is something the application can change. Muted/unmuted is 
something the application can't influence. The user should be able to 
mute using a button in the browser chrome, or a button on the headset. 
The application should not be able to unmute if the user has muted for 
obvious reasons.

So the naming may be confusing (and should perhaps be changed), but I 
think that we can't collapse mute/unmute and enable/disable into one thing.

Stefan

>
>
> So here is what I can find in the draft on the meanings of these
> today, and the above recommendation does not change the meanings from
> what they are, it just tries to clear up the working. Feel free to
> ignore the rest of this email, the important things is the above
> proposal to fix it
>
>
> The ready-state can be one of
>
> new - track type is new and has not been initialized
>
> live - The track is active (the track’s underlying media source is
> making a best-effort attempt to provide data in real time). The
> output of a track in the live state can be switched on and off with
> the enabled attribute.
>
> muted - The track is muted (the track’s underlying media source is
> temporarily unable to provide data).
>
> ended - The track has ended (the track's underlying media source is
> no longer providing data, and will never provide more data for this
> track).
>
> So looking at this, it looks like toggling the enable bit moves the
> state back and forth from live to muted.
>
>
> Then we have muted and unmated events and related callbacks that
> correspond to the state be muted and live.
>
> We have the text
>
> Each track in a MediaStream object can be disabled, meaning that it
> is muted in the object’s output. All tracks are initially enabled.
>
> The output of a MediaStream object must correspond to the tracks in
> its input. Muted audio tracks must be replaced with silence. Muted
> video tracks must be replaced with blackness.
>
> Later we have text that implies "live" has to do with if it is coming
> from a file or not, and nothing to do with being the opposite of
> muted.
>
> As a side note I despise text like
>
> The readyState attribute represents the state of the track. It must
> return the value to which the user agent last set it.
>
> There is not a single bit of useful information in that paragraph for
> someone trying to implement this or someone trying to use it.
>
>
>
>
>
Received on Friday, 22 March 2013 13:43:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:15 UTC