- 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>
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