Re: Configuring codecs

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.

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

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

Received on Thursday, 15 October 2015 17:40:09 UTC