Re: Configuring codecs

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.

Received on Thursday, 15 October 2015 20:17:37 UTC