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

On 03/20/2013 03:33 PM, Adam Bergkvist 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.
>>
>> 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.
A track doesn't make any sense before it's connected to at least one 
sink (it's completely logical for the implementation to defer all real 
action on the track until it's connected), so that seems to be 
consistent with our current model.

<mantra repeat=often>It's just a control surface. There are no 
bytes.</mantra>

Received on Wednesday, 20 March 2013 14:45:40 UTC