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

What would be the advantage of treating tracks differently depending on who
created them?
Silvia.
 On 27 Sep 2013 22:28, "Harald Alvestrand" <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<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
>>
>>
>
>