- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Wed, 30 Apr 2014 07:45:45 +0200
- To: Martin Thomson <martin.thomson@gmail.com>, Jan-Ivar Bruaroey <jib@mozilla.com>
- CC: <public-webrtc@w3.org>, Justin Uberti <juberti@google.com>
On 2014-04-30 02:06, Martin Thomson wrote: > > On Apr 29, 2014 4:54 PM, "Jan-Ivar Bruaroey" <jib@mozilla.com > <mailto:jib@mozilla.com>> wrote: > > > > On 4/29/14 7:07 PM, Martin Thomson wrote: > >> > >> I was talking about clone-on-RTCPeerConneciton::addStream > > > > > > Forcing me, as a user, to clone my MST if, and only if, I want to add > it to more than one PeerConnection seems to have little to no cost to > me, and seems like a reduction in complexity. > > I might be missing something, but why do we need cloning? In the general case, cloning is about getting a new MediaStreamTrack instance to, e.g., apply constraints to and control the enabled attribute. Use case: you're sending a MST to two peers and you want to mute audio to one of them. The API surface introduced by the DooHickeys makes cloning less important in the RTCPeerConnection case since the consumer creates a representation of the track being sent that is different from sending the track to an other peer. /Adam
Received on Wednesday, 30 April 2014 05:46:10 UTC