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

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

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 20 Mar 2013 15:55:03 +0100
Message-ID: <5149CDC7.6030203@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
CC: Jim Barnett <Jim.Barnett@genesyslab.com>, Martin Thomson <martin.thomson@gmail.com>, Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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

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