- 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>
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