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

Re: Proposal related to bug 22270 "Adding tracks to MediaStream should only be possible for constructed streams"

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 25 Oct 2013 18:04:11 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3C6B88@ESESSMB209.ericsson.se>
On 25/10/13 19:04, Martin Thomson wrote:
> On 25 October 2013 03:43, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>>> Is there value in having the UA police whether or not one can add tracks
>>> to an UA-constructed MediaStream?
>
> I have no reasons to prevent this.  I appreciate the reasons roc
> outlines, but honestly, most of the real machinery here is on the
> tracks, not the container.

The only case when I can see it could matter is:

1. Assume the app at the remote end of a PeerConnection, that receives 
two MediaStreams A and B, and that track X with id id_X is part of both 
of them.
2. Assume further that the app really wants to make sure that track X is 
in MediaStream A, and does so by

     MS_A.addTrack(MS_B.getTrackById(id_X));

If now the app on the sending side at approximately the same time 
removes track X from MS A there is a race condition. If the track is 
removed before track X is added on the receiving side it will be 
re-added by the operation above, but if the removal happens after then 
MS_A on the receiving side would not contain track X.

This is a very constructed example, and the app could listen to 
removetrack events (and could add again), so I'm not sure it is a 
motivation to make separate MediaStream types.

>


Received on Friday, 25 October 2013 18:04:35 UTC

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