Re: Configuring codecs

On 12 October 2015 at 22:04, Peter Thatcher <pthatcher@google.com> wrote:
> 1.  This will work with createAnswer, correct?

Yes.

> 2.  Does this applies to all RtpSenders?   What if the app wants different
> codecs for different RtpSenders?

Yes, this is global.  I imagine that it applies to receivers too.  I
didn't consider the asymmetry to be important here.  If something is
available to sending or receiving only, then it can be added to the
list and the UA can just cope.

> 3.  If {codecs: ...} is not provided in a subsequent createOffer, does it
> use the last given value or revert to the default?

It can revert.  Which I assumed would be the default.

> 4.  Did you consider put {codecs: ...} on addTransceiver or addTrack?  It
> might make sense there as a per-RtpSender option that is set once rather
> than for each call to createOffer.  On the other hand, it's not as easy to
> use that for controlling what happens in createAnswer.

I did.  Currently, there is no addTransceiver and addTrack doesn't
offer any place for options.  But that's just an excuse, the major
reason is that this is simpler.  I'm not opposed to adding something
later, but if we think that's a good idea, then we should put this
stuff on ice until we have more of the infrastructure in place.

> On Mon, Oct 12, 2015 at 3:08 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> We now have a tool for configuring the codecs that we use once they
>> are negotiated.  However, we don't have a way to guide the negotiation
>> part.  Until:
>>
>>    https://github.com/w3c/webrtc-pc/pull/326
>>
>> Now, all you need to do is acquire some capabilities...
>>
>> var codecs = RTCRtpSender.getCapabilities().codecs;
>>
>> ...filter and reorder...
>>
>> codecs = codecs.filter(isCodecGood);
>> codecs.sort(whichCodecIsBetter);
>>
>> ...and then
>>
>> pc.createOffer({codecs: codecs})
>>   .then(profit)
>>
>

Received on Tuesday, 13 October 2015 18:14:40 UTC