W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2012

RE: Could we remove enable/disable from MediaStreamTrack?

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Tue, 14 Aug 2012 22:02:03 +0000
To: Jim Barnett <Jim.Barnett@genesyslab.com>, Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B3838403EA1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
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

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