Re: senders vs receivers codec selection

Currently the receiver has a payload type for each codec. This 
configuration allows the receiver can receiver with any codec on the 
same SSRC and allow auto-switching between them. This ability is true so 
long as the codec is not SVC enabled because the layering information 
was defined within the context of the receiver object itself and not 
within the context of receiver's codec.

If the receiver object is only supposed to work with a particular codec 
only then why are we supplying the receiver object with a set of codecs 
and payload type for each codec? So to me, that suggests the receiver 
object CAN switch between codecs. If does allow this behaviour then why 
doesn't it then work too for SVC codecs but only non SVC codecs?

To me this implies we should do one of the following:
1) make the sender / receiver only have one codec and that's it. Want to 
receive or send with a different codec? Use a different sender / 
receiver object. -OR-
2) make the sender / receiver work for all codecs equally by defining 
the layering within the context of the SVC codec and not within the 
context of the receiver

I'm completely fine with either scenario "1" or "2" but I don't like the 
way it kind-of half works now. "2" is more work for ORTC implementors 
but it allows for easier management of the receiving streams for an 
application developer.

-Robin


> Bernard Aboba <mailto:Bernard.Aboba@microsoft.com>
> May 11, 2014 at 8:10 PM
> I have been assuming that a receiver always needs to specify the 
> payloadType (e.g. It cannot be missing or null), even if there is an 
> SSRC specified.
>
> Robin Raymond <mailto:robin@hookflash.com>
> May 11, 2014 at 10:41 AM
>
> My understanding was this:
> A RTCRtpSender picks a single codec for sending but a receiver can 
> receive on any of the defined RTCRtpCodecs.
>
> Here's a few questions:
> a) If a sender wants to change sending codecs, do they setup a new 
> sender object?
>
> b) If a receiver latches onto a stream with a particular payload type, 
> is that latch permanent (i.e. if sender changes sending codecs, does a 
> new receiver need to be setup to receive a payload type even on the 
> same SSRC)?
>
>
> As things are defined now, the sender must pick a sending codec. The 
> receiver does not have enough information to receive upon any codec 
> because the layering information only works for one codec's scenario 
> (despite having a list of codecs available) thus the receiver can only 
> receive upon one payload type.
>
> -or-
>
> The receiver can only work on one codec if using SVC, but can switch 
> between codecs if the other codecs are not configured using SVC (since 
> only one SVC scenario can be setup).
>
>
> Therefor, it's doesn't appear to be currently possible for the 
> receiver to configure a bunch of SVC codecs and then the sender pick 
> which one to use, even though the receiver can configure a bunch of 
> non-SVC codecs and can have the sender pick which one to use.
>
>
> I want to confirm my understanding is correct (and if others agree 
> that this should be correct).
>
> -Robin
>