- From: Justin Uberti <juberti@google.com>
- Date: Wed, 29 Apr 2015 21:54:44 -0700
- To: Peter Thatcher <pthatcher@google.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOJ7v-1im=6PoohqyV2LJ3kEwCH+rX9gsvKXad17nfx=HKxOEA@mail.gmail.com>
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