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

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.
>