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

Re: Proposal: Add RtpSenderInit parameter to addTrack.

From: Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 30 Apr 2015 01:12:32 -0400
Message-ID: <5541B9C0.5090103@jesup.org>
To: public-webrtc@w3.org
On 4/30/2015 12:54 AM, Justin Uberti wrote:
> This seems like a smart approach; I find points #1/#3 especially 
> persuasive.

As do I.   Especially with something with potentially a lot of options, 
and where adding options is likely, this sort of named parameter 
approach via an Init object/dict is definitely a win.

> On Tue, Apr 21, 2015 at 4:06 PM, Peter Thatcher <pthatcher@google.com 
> <mailto:pthatcher@google.com>> wrote:
>     While talking to Stefan about the possibility of per-RtpSender
>     control of VAD, and thinking about all the recent discussion
>     around MSID, I realized that there was a common need to add
>     parameters to addTrack.
>     I propose we add a dictionary parameter "RtpSenderInit", like we
>     have DataChannelInit that contains parameters for
>     PeerConnection.createDataChannel without making the parameter list
>     a mess.


>     Let's continue the discussion around voiceActivityDetection,
>     synchronizationGroups, and label/ID on separate threads, but for
>     this thread, I'd like to ask the group:  Does it look like a good
>     idea to follow the createDataChannel(..., DataChannelInit) pattern
>     by having addTrack(..., RtpSenderInit)?
>     I'm in favor of it because:
>     1.  We'd avoid with a mess of parameters in addTrack over time.
>     2.  It gives the app to specify initial RtpParameters (such as
>     VAD, potentially).
>     3.  It follows the same pattern we already have for
>     createDataChannel, which has been successful in adding many
>     options without making the parameter list a mess.
>     4.  It gives us more flexibility in our work around IDs and labels.

Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam
Received on Thursday, 30 April 2015 05:12:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC