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

Re: Proposal: Add RtpSenderInit parameter to addTrack.

From: Justin Uberti <juberti@google.com>
Date: Wed, 29 Apr 2015 21:54:44 -0700
Message-ID: <CAOJ7v-1im=6PoohqyV2LJ3kEwCH+rX9gsvKXad17nfx=HKxOEA@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
This seems like a smart approach; I find points #1/#3 especially persuasive.

On Tue, Apr 21, 2015 at 4:06 PM, Peter Thatcher <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.
>
> IDL that would retain current semantics could look like this:
>
>
> partial interface PeerConnection {
>     RtpSender addTrack(MediaStreamTrack track, RTCRtpSenderInit init);
> }
>
> dictionary RTCRtpSenderInit {
>   sequence<MediaStream> streams;
> }
>
>
> A more advanced form, if we choose to add more parameters later, could
> look like this:
>
> dictionary RTCRtpSenderInit {
>   // These are based on our discussion of MSID.
>   DOMString label;
>   sequence<DOMString> synchronizationGroups;
>
>   // The initial RtpParameters to use, as if you call .setParameters
> immediately after
>   // calling addTrack.
>   RtpParameters parameters;
> }
>
> ​dictionary RtpParameters {
>   // This is based my discussion with Stefan.
>   boolean voiceActivityDetection;
> }​
>
>
>
> 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.
>
> Thanks,
> Peter
>
>
Received on Thursday, 30 April 2015 04:55:31 UTC

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