Re: Configuring codecs

This sounds good to me:

var sender = pc.addTrack(track);
sender.transceiver.setCodecsPreferences(codecs);


I like how it's per-transceiver and it also allows the answerer to set
preferences like so:

pc.ontrack = function(e) {
  e.transceiver.setCodecPreferences(codecs);
};


And if we go down this route, can we also replace "voiceActivityDetection"
with this, since really it's just a codec preference of whether to include
CN or not (right?).

On Thu, Oct 15, 2015 at 1:17 PM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> On 10/15/2015 07:39 PM, Martin Thomson wrote:
> > Let's step back for a second and ask: why transceiver?
> >
> > The capabilities are separate properties of the sender and receiver.
> > So if anything, they are things that belong there.  Maybe the right
> > way to deal with this is to have those objects accept codec
> > preferences.
> >
> > The problem, of course, is SDP.  We can't designate a given codec as
> > sendonly or recvonly.  Which is not a problem with the API, but a
> > fundamental problem with SDP, because there are cases where the
> > offerer has to include an advertisement for codecs that it can only
> > send or only receive if there is any case where support is asymmetric.
> Yes, that's my thinking.
>
> The transceiver represents an union of a sender and receiver that exists
> because SDP says it must. A transceiver's codec configuration would
> apply equally to sender and receiver because SDP says it must.
>
> A chief advantage of the transceiver object is that it allows us to keep
> the things that are the way they are because SDP says they must be that
> way in one place.
>
> (The preference sequence is actually, if I interpret offer/answer
> correctly, permitted to be different between the sender and the
> receiver. So that needs to be able to percolate down.)
>
> >
> > Assuming that we can get past that - I assume that we will continue to
> > stick our fingers in our ears and sing loudly as we have done thus far
> > - I don't see a way to modify addTrack that is backward compatible.  I
> > would rather just tweak the sender/receiver.
> >
> > var sender = pc.addTrack(track);
> > sender.setCodecPreferences(codecs);
> > sender.transceiver.receiver.setCodecPreferences(codecs);
> >
> > or perhaps:
> >
> > var sender = pc.addTrack(track);
> > sender.transceiver.setCodecPreferences(codecs);
> >
> > This isn't going to be that common, a few hoops are fine.  (I prefer
> > the former, unless we intend to move getCapabilities().
>
> As I was writing my previous note, I was actually thinking that setting
> the codec preferences after the transceiver was created (but before
> offer/answer) was a perfectly acceptable strategy too - in which case
> addTrack doesn't need it either.
>
> addTrack is a simplification over pure transceiver manipulation. Keeping
> it simple seems like a win.
>
> >
> > On 15 October 2015 at 01:16, Harald Alvestrand <harald@alvestrand.no>
> wrote:
> >> 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>
> >> 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.
> >>
> >>
> >> 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>
> >>>> 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)
> >>>>>
> >>
> >>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>
>
>