Re: Track cloning behavior of MediaStream() constructor and addTrack()

On 2013-03-20 13:38, Harald Alvestrand wrote:
> On 03/20/2013 12:44 PM, Jim Barnett wrote:
>> There's also a question of what it means for a Track to be attached to
>> a sink.  The MediaRecorder class takes a MediaStream as its input, not
>> an individual Track.  Does the Recorder serve as a sink for both the
>> MediaStream and its Tracks?  My guess is that it does, and that in
>> general whenever a MediaStream is attached to a sink, all its Tracks
>> are as well, but we would need to make this explicit.
>
> That's been the only meaning I have been able to attach to "A
> MediaStream is attached to a sink". Being explicit is always good.

Yes. I should have been more clear that the track is "connected to the 
sink" as a result of its "parent" MediaStream being connected to the sink.

> BTW, if we are able to attach one MediaStream to multiple sinks (which I
> think we want to do), by that logic we also are attaching one
> MediaStreamTrack to multiple sinks; we've discussed usage cases for that
> multiple times in the past (sending the same stream to multiple
> PeerConnections + a local preview window + a recorder, for instance).

Yes, or at least we're connecting one source to multiple sinks.

This leads us to the topic we just discussed. We could have a 
restriction that each sink must consume a source via a unique 
MediaStreamTrack instance. That was a restriction I didn't really see a 
need for (with the control surface perspective of tracks).

/Adam

Received on Wednesday, 20 March 2013 14:55:28 UTC