RE: Could we remove enable/disable from MediaStreamTrack?

I think this is moving in the right direction.

> -----Original Message-----
> From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
> Sent: Friday, August 10, 2012 7:49 AM
> To: Stefan Hakansson LK; public-media-capture@w3.org
> Subject: RE: Could we remove enable/disable from MediaStreamTrack?
> 
> So a single  track could be enabled for one consumer and disabled for
> another, while muting it would stop output to all consumers.  I think that
> would work.
> 
> - Jim
> 
> -----Original Message-----
> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> Sent: Friday, August 10, 2012 9:55 AM
> To: public-media-capture@w3.org
> Subject: Could we remove enable/disable from MediaStreamTrack?
> 
> Hi all,
> 
> a thought on Friday afternoon.
> 
> For a MediaStreamTrack, there are currently the states:
> 
> * muted/unmuted
> * enabled/disabled
> 
> The idea is that enabled is controlled by the application; while mute is
> controlled by the browser and overrides enable. This way, the browser can
> e.g. allow the user to mute the microphone, and the application can not
> override.
> 
> Using the enable/disable, the application can e.g. stop playing audio and/or
> video by disabling the corresponding MediaStreamTracks on a MediaStream
> connected to a video element.
> 
> However, in its latest incarnation, the audio and video elements allow the
> application to select which track(s) to play by using the enabled
> (audio) and selected (video) attributes. See
> http://dev.w3.org/html5/spec/media-elements.html#media-resources-
> with-mu
> ltiple-media-tracks
> for more info.
> 
> I think we should consider adopting this model, i.e. that the consumer is the
> place where what track(s) that are used is selected, rather than having it on
> two places (MediaStreamTrack _and_ media elements).
> 
> I think we should consider it since it can avoid confusion (e.g., what should
> happen if a track is disabled by setting "enabled" to false on that
> MediaStreamTrack but the same track is "enabled" in the media element?).
> Another advantage(?) is that the app would have less reasons to clone
> MediaStreams to allow independent control as this is handled by controlling
> the individual consumers instead.
> 
> If we change this way, this would essentially mean that:
> 
> * the enabled attribute is removed from MediaStreamTrack (mute remains)
> * for a MediaStream connected to an audio or video element, selection of
> rendered tracks is done using the mechanism already available there
> * for the (yet to be defined) record function, it must be possible to
> enable/disable tracks to record on the recorder (rather than by
> enabling/disabling tracks on the MediaStream to be recorded)
> * for an object sending MediaStreams over the network to a peer,
> possibilities to enable/disable tracks similar to what is available for
> audio/video elements need to be defined (a task for the webrtc WG)
> 
> What do you say? Does this make any sense?
> 
> Br,
> Stefan
> 
>

Received on Tuesday, 14 August 2012 22:02:36 UTC