- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 30 Apr 2015 05:29:52 +0000
- To: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
I like this approach.
Stefan
On 22/04/15 01:10, Peter Thatcher 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 05:30:19 UTC