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

On 2013-09-27 23:46, Silvia Pfeiffer wrote:
> What would be the advantage of treating tracks differently depending on
> who created them?

I think this was originally brought up by Rob [1].

To me treating them differently would be mostly about clarity. We have 
this model of that when a MediaStream is sent over a PeerConnection, the 
MediaStream at the remote end is a copy of the MediaStream added to 
PeerConnection at the sending side - it contains the same tracks. And if 
tracks are removed or added to the MediaStream on the sending side that 
will - given that the SDP O/A is carried out - be reflected at the 
remote end (and andtrack/removetrack events will be fired).

But, if the app at the remote end adds or removes tracks, will that 
propagate back to the sender? The answer is clearly "no", but if we 
remove the possibility for the app (at the receiving end) to add or 
remove tracks we take away this question since it is not possible.

Stefan

[1] 
http://lists.w3.org/Archives/Public/public-media-capture/2013Apr/0127.html


> Silvia.
>
> On 27 Sep 2013 22:28, "Harald Alvestrand" <harald@alvestrand.no
> <mailto:harald@alvestrand.no>> wrote:
>
>     Reawakening an old discussion (tracked in bug 22270).
>
>     The suggestions made are (I think) three different ones:
>
>     - Create two classes of MediaStream, one which adds tracks under UA
>     control, and one which adds tracks under Javascript control. Only
>     the second has the addTrack and removeTrack methods. getUserMedia
>     and peerconnections produce the first type.
>
>     - Let addTrack and removeTrack fail when a MediaStream comes from
>     getUserMedia or peerconnections.
>
>     - No change. Tracks can be added to any MediaStream.
>
>     Should we make a decision here?
>
>
>     On 04/18/2013 11:09 AM, Adam Bergkvist wrote:
>
>         On 2013-04-17 12:23, Robert O'Callahan wrote:
>
>             On Wed, Apr 17, 2013 at 10:18 PM, Adam Bergkvist
>             <adam.bergkvist@ericsson.com
>             <mailto:adam.bergkvist@ericsson.com>
>             <mailto:adam.bergkvist@__ericsson.com
>             <mailto:adam.bergkvist@ericsson.com>>> wrote:
>
>                  Since they're only used to listen to when the UA
>             updates the track
>                  set they wouldn't be used when it's only the
>             application that
>                  manages the track set.
>
>                  This is a bit confusing in the current spec. The
>             description of the
>                  events say that they are fired whenever a track is
>             added, which is
>                  misleading since they are not fired in the
>             addTrack()/removeTrack()
>                  algorithms. It's fixed for the next release.
>
>
>             We should also fire them when addTrack()/removeTrack() are
>             called,
>             shouldn't we?
>
>
>         We currently don't do that since these methods directly adds or
>         removes the track. In the case where it's the UA that modifiess
>         the track set, the track is added/removed in the same event loop
>         iteration as the addtrack/removetrack event is fired.
>
>         I don't have a strong preference about this; if we could find
>         similar behavior in established APIs I would be happy to align.
>
>         /Adam
>
>
>

Received on Saturday, 28 September 2013 05:05:33 UTC