Re: Configuring codecs

Den 20. okt. 2015 20:52, skrev Peter Thatcher:
> 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);
> };

or slightly longer:


e.transceiver.setCodecPreferences(massageCodecPreferences(e.transceiver.getCodecPreferences()))

since the set of codecs from which preferences can be made isn't known
until the event.

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

I'd like to think of it as "can explain voiceActivityDetection in terms
of...", but yes.

> 
> On Thu, Oct 15, 2015 at 1:17 PM, Harald Alvestrand <harald@alvestrand.no
> <mailto: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 <mailto: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 <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)
>     >>>>>
>     >>
>     >>
> 
> 
>     --
>     Surveillance is pervasive. Go Dark.
> 
> 
> 
>

Received on Tuesday, 20 October 2015 19:08:32 UTC