- From: Alexandre GOUAILLARD <agouaillard@gmail.com>
- Date: Sat, 1 Aug 2015 07:01:40 +0900
- To: Peter Thatcher <pthatcher@google.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAHgZEq7im1N+V4wOAcAqDT2_Zvr_ihxZWdbr0jcMaUappvmLZQ@mail.gmail.com>
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