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