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

Re: Proposal for a way to set the send codec on an RtpSender.

From: Alexandre GOUAILLARD <agouaillard@gmail.com>
Date: Sat, 1 Aug 2015 07:01:40 +0900
Message-ID: <CAHgZEq7im1N+V4wOAcAqDT2_Zvr_ihxZWdbr0jcMaUappvmLZQ@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
I confirm there is a lot of interest in being able to do this without
touching the SDP.

On Fri, Jul 24, 2015 at 9:09 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> I made https://github.com/w3c/webrtc-pc/pull/258 to show what I'm
> suggesting we add.
>
> Is there any interest out there for allowing the JS to control the send
> codec without SDP munging?  I've spoken to many application developers that
> want it, but I've gotten silence on the list so far.
>
> On Thu, May 28, 2015 at 2:51 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
>> When I meet up with application developers one of the first things they
>> want to know is how to change codecs.   And the response "well, you can
>> munge SDP" never goes over very well.
>>
>> So, I've been thinking about a way we can allow developers/apps to
>> control the codecs without munging SDP, but also without adding a lot of
>> complexity to the API.  And now that we have RtpSenders and
>> RtpSender.setParameters (at least in this PR:
>> https://github.com/w3c/webrtc-pc/pull/234), I think there is a way.
>>
>> I propose we allow apps to do this:
>>
>> var params = sender.getParameters();
>> var myFavoritePayloadType;
>> for (var i = 0; i < params.codecs.length(); i++) {
>>   if (params.codecs[i].name == "myFavoriteCodec") {
>>     myFavoriatePayloadType = params.codecs[i].payloadType;
>>   }
>> }
>> if (myFavoritePayloadType) {
>>   params.encodings[0].payloadType = myFavoritePayloadType;
>>   sender.setParameters(params);
>> }
>>
>>
>>
>> In other words, an app can:
>> 1.  Get all the codecs currently available.
>> 2.  Find the one it wants to send with (by name or other attributes).
>> 3.  If it's available, choose it (by an ID, and the ID we use is
>> payloadType).
>>
>>
>> And we can accomplish that by adding the following to RTCRtpParameters:
>>
>> partial dictionary RTCRtpParameters {
>>   sequence<RTCRtpCodecParameters> codecs;
>> }
>>
>> dictionary RTCRtpCodecParameters {
>>   unsigned short payloadType;
>>   DOMString name;
>>   unsigned short channels;  // mono=1, stereo=2
>> }
>>
>> partial dictionary RTCRtpEncodingParameters {
>>   unsigned short payloadType;
>> }
>>
>> An alternative would be to allow the app to alter
>> RTCRtpParameters.codecs, such as by reordering them.  But I think allowing
>> the app to alter RTCRtpParameters.codecs opens up too much complication,
>> because potentially that would change the SDP.
>>
>> And, naturally, we could add more things to RTCRtpCodecParameters: such
>> as clockrate and codec parameters.   But we should probably stick with the
>> ones that an app would actually want to use for selecting among several
>> codecs.
>>
>>
>> In summary, I think this is a reasonably low-complexity way of adding
>> something that's very valuable to applications and developers and builds on
>> top of the work we've already done with RtpSender.
>>
>
>


-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -
Received on Friday, 31 July 2015 22:02:08 UTC

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