Re: addTrack/removeTrack on gUM streams and PeerConnection remote streams

On 4/15/13 1:38 PM, Robert O'Callahan wrote:
> On Mon, Apr 15, 2013 at 11:28 PM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     There are some use-cases which can be handled better if
>     add/removeTrack is possible, but if complex to implement I would
>     personally be open to omit that from a first version (especially if
>     we decide that synchronization context spans all tracks originating
>     from the same end-point, not only the tracks in one MediaStream). We
>     could add it as a later extension.
>
>
> What does it mean for a script to remove a MediaStreamTrack from a gUM
> stream or a PeerConnection remote stream? Does that have any side
> effects? Maybe it's just me but it seems weird that a script could, say,
> swap the tracks between a gUM stream and a PeerConnection remote stream.

I know Adam at one point brought forward the idea of a something like a 
RemoteMediaStream (i.e. a stream received from a remote end-point) which 
would no have any add/removeTrack methods.

> It would be extra weird if we ever create any subclasses of MediaStream.
>
> Use-cases that need add/removeTrack can always construct their own
> MediaStream with borrowed tracks.

Yes, they can. But I see a benefit in addTrack e.g. for

* An audio conference with local mixing; there is a button "record" 
available. If one more participant joins, it would be nice if that audio 
track could just be added to the (constructed) MediaStream being 
recorded. Otherwise you'd have to construct a new MediaStream (with all 
participants), start recording it, stop recording the old one - and you 
have to deal with syncing the recorded material

* A device has no camera, a communication session is set up with audio 
only. The user plugs in a camera (which the app can detect with the 
recent additions). It feels like the risk of an audio glitch when 
playing out at the other end would be lower if the video track could 
just be added rather than creating a new MediaStream with both audio and 
video.

That said, my personal view is that we could live without 
add/removeTrack initially.

>
> Rob
> --
> q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
> qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
> qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q
> qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq
> qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq
> qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

Received on Monday, 15 April 2013 11:55:27 UTC