W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2013

RE: How do we enable/select tracks for playout?

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>
Message-ID: <9768D477C67135458BF978A45BCF9B3853C4CAAB@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
> 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

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