W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2014

Re: Update of RTCRtpSender "doohickey" proposal

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 30 Apr 2014 07:45:45 +0200
Message-ID: <53608E09.1080604@ericsson.com>
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.

Received on Wednesday, 30 April 2014 05:46:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:55 UTC