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

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

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 20 Mar 2013 15:33:30 +0100
Message-ID: <5149C8BA.1070104@ericsson.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
CC: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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.
> It is useful to have a mute/disable function on the sending side, the
> substitutes black frames for video, just like 'mute' in audio.  This
> shouldn't necessarily have any impact on the sink (though if it's
> smart enough to detect the muting and wants to switch to another
> track, that's fine).
> 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.

On the other hand, such an on/off switch doesn't make sense until 
there's at least one sink to consume the output. But perhaps that's OK.

Received on Wednesday, 20 March 2013 14:33:54 UTC

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