Re: Configuring codecs

On 10/15/2015 07:24 AM, Peter Thatcher wrote:
>
>
> On Tue, Oct 13, 2015 at 11:14 AM, Martin Thomson
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     On 12 October 2015 at 22:04, Peter Thatcher <pthatcher@google.com
>     <mailto: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.

I think codec preferences that influence the SDP negotiation belong in
the RTPTransceiver object.

This means that:

1) They have to be accessible (gettable and settable) on that object.
2) They have to be available when creating the object.

Most RTPTransceivers will (in my picture of the world) be created by
calling addTrack, which calls the internal function that creates the
RTPTransceiver when it can't reuse an RTPTransceiver (have to put it
like this since the rule against referring to public interfaces means
that I can't say "calls the constructor for RTPTransceiver" ... grumble
...) which means that there has to be a way to pass it to addTrack.

It also means that codec preferences get to be a selection parameter
when addTrack() has to decide whether it can reuse an RTPTransceiver or
not - if the codec preferences are different, it can't reuse the
transceiver, because that would create two different expectations of
what would go into the SDP when calling createOffer.

Conclusion:

- There has to be a get/set interface for codec preferences on
RTPTransceiver
- The RTPTransceiver constructor has to have a place to pass codec
preferences
- addTrack has to have a way to let the user indicate codec preferences.

The way forward should be clear :-)

(if I'm right....)
> ​
>  
>
>
>     > On Mon, Oct 12, 2015 at 3:08 PM, Martin Thomson
>     <martin.thomson@gmail.com <mailto: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)
>     >>
>     >
>
>