- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Wed, 20 Mar 2013 17:32:49 +0000
- To: Martin Thomson <martin.thomson@gmail.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>
- CC: Jim Barnett <Jim.Barnett@genesyslab.com>, Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
> From: Martin Thomson [mailto:martin.thomson@gmail.com] > On 20 March 2013 07:33, Adam Bergkvist <adam.bergkvist@ericsson.com> > wrote: > > On 2013-03-19 14:00, Jim Barnett wrote: > >> > >> The final decision of what to display should be up to the sink. If > >> there are sinks that can handle MediaStreams containing multiple > >> audio or video tracks, then they should be able to use whatever > >> heuristics they want to select the Track(s) to play out. > > I'm concerned with the non-deterministic behaviour that could happen if we > don't make something explicit here. > > >> The big question is what to do when we have a MediaStream that > >> contains multiple Tracks, and a sink that can play out only one. In > >> that case, we could say that the real interface to the sink is the > >> Track, and leave it up to the API to select the Track that it wants > >> to pass to the sink. Alternatively, if we there are reasons to keep > >> MediaStream as the interface, we could add the concept of > >> 'defaultVideoTrack' and 'defaultAudioTrack' to the MediaStream. This > >> wouldn't change the behavior the sending end at all, but simply be a > >> signal "If you are streamed into a sink that can only handle a single > >> Track, use this one". > > > > I think this makes sense in a way. The enable/disable is just a switch > > on the tracks that turns the "output" on or off, and doesn't > > necessarily have anything to do with how the sink chooses which tracks to > > render. This is how I've always assumed that it worked.... > This alternative is exactly what I want, though "activeVideoTrack" and > "activeAudioTrack" might be more appropriate names. You could > automatically populate these attributes with the first track of each type that > is added so that simple uses are supported. > > One other advantage is that "muting" can then be achieved by setting this > mutable property to null/undefined. If something isn't active, then it isn't > rendered. So as I understand, setting enabled=false does not cause the 'muted' event to fire, right? But you're proposing that setting activeVideo/AudioTrack to null/undefined would cause this event to fire? Is 'muted' (the event name) still a good name for the "absence of media content" state?
Received on Wednesday, 20 March 2013 17:33:57 UTC