Re: Configuring codecs

On Tue, Oct 13, 2015 at 11:14 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

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

​We can easily add more params to addTrack.  There was previously consensus
on replacing the "... streams" of addTrack with a dictionary that has
.streams in it.  But I abandoned that CL because there didn't end up being
anything other than streams to put in there.  But if you have something, we
could bring that idea back.

However, putting it on addTrack/addTransceiver does not allow the answerer
to indicate a codec preference via createAnswer, so this approach does have
that advantage.  And if an application wants per-sender codecs, it could
always use RtpSender.setParameters.  So putting it in createOffer might be
a better approach.  It does cover the simple use cases well and I can't
think of a good reason to not put it there.
​


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