- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 16 Aug 2013 07:36:57 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: Iñaki Baz Castillo <ibc@aliax.net>, Justin Uberti <juberti@google.com>, José Luis Millán <jmillan@aliax.net>, "public-media-capture@w3c.org" <public-media-capture@w3c.org>
On 2013-08-16 01:14, Martin Thomson wrote: > On 15 August 2013 16:03, Iñaki Baz Castillo <ibc@aliax.net> wrote: >> Much better cloning it. Cloning allows each track being controlled >> separately (regardless they both share the same original source). > > Unless by cloning it you lose synchronization, or you end up with > simulcast instead of a single stream. There's no guarantee that a > cloned track is rendered synchronously with other tracks from the same > source - the only guarantee applies to tracks in the same MediaStream. > That's actually unlikely. > > More to the point, by not cloning, I avoid potential issues with > configuration changes causing the source to become overconstrained. > And maybe I want to manage changes globally. I looked up the last summary of this discussion [1]. I think the most relevant part in this case is: 'One still open question is whether a track can be a member of multiple streams; there are ease-of-implementation issues that argue for saying "no"; there are orthogonality arguments that argue "yes".' I think that is where we stand. Against allowing 'shared' tracks are ease-of-implementation arguments, for allowing 'shared' tracks are orthogonality (which perhaps can be put as ease-of-use) arguments. Stefan [1] http://lists.w3.org/Archives/Public/public-media-capture/2013May/0081.html
Received on Friday, 16 August 2013 07:37:29 UTC