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 Friday, 10 August 2012 14:49:48 UTC