Re: RtpParameters encodings: leave the door open for many, or There Can Only Be One?

There are downsides to having one RtpSender per simulcast layer (which is
another way of looking at simulcast vs track cloning):

1.  If the encodings are dependent on one another (layered encodings, not
simulcast), now you have RtpSenders dependent on other RtpSenders, which
gets complicated.  Keeping the layers within one RtpSender with one set of
RtpParameters is easier to manage.

2.  If you want to receive simulcast, you need more than one RtpReceiver,
but you want to render them to the same location on the screen.  Doing that
at the application level is difficult, if not impossible, to do well.  Why
would you want to receive simulcast?  here are a few possible reasons: A.
You want an SFU that doesn't do SSRC rewriting (possibly to do end-to-end
encryption without RTP header munging).  B.  You want a full mesh where the
senders only encode and packetize once, and send the same packets to each
receiver (with possibly different subsets to each).  There are probably
other good reasons to support one RtpReceiver with multiple encodings.

3.  Adding a track or RtpSender requires renegotiation.  Adding an encoding
to an RtpSender wouldn't necessarily require renegotiation.

4.  When not using BUNDLE, adding a a track or RtpSender requires a new
transport.  Adding an encoding to an RtpSender wouldn't.

5.  It conflicts with the model of simulcast in SDP progressing in MMUSIC
where multiple encodings are represented as distinct payload types in the
same m-line.  Since one RtpSender == one m-line, if one RtpSender == one
encoding, then it would be impossible to represent the simulcast in SDP
progressing in MMUSIC where one m-line == N encodings (via payload types).







On Mon, Jun 8, 2015 at 4:34 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> I had (perhaps foolishly) thought this would be done by track cloning. Is
> that dumb?
>
> -Ekr
>
>
> On Mon, Jun 8, 2015 at 4:10 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
>> And my opinion on the matter:
>>
>> I think if we lock it down to one encoding, we're paining ourselves into
>> a corner, and we'll be stuck with figuring out how to expand it multiple
>> encodings later, which may be painful.  Thus, I am in favor of multiple
>> encodings.  However, I see the reasoning behind making the single-encoding
>> use case more simple.   And  I see value in the rule of "properties shared
>> by all encodings".  But I'm not completely sure it's worth the additional
>> complexity (of having parameter in two places and not just one).
>>
>>
>>
>>
>> On Mon, Jun 8, 2015 at 4:07 PM, Peter Thatcher <pthatcher@google.com>
>> wrote:
>>
>>> Recently, I wrote up a PR reflecting what I thought we (roughly) agreed
>>> up on at TPAC 2014: https://github.com/w3c/webrtc-pc/pull/234.
>>>
>>> In it, I basically added this:
>>>
>>> dictionary RtpParameters {
>>>   sequence<RtpEncodingParameters> encodings;
>>> }
>>>
>>> dictionary RtpEncodingParameters {
>>>   bool active;
>>>   float priority;
>>> }
>>>
>>>
>>> You'll notice that this leaves open the door for multiple encodings per
>>> RtpSender, for example for simulcast.  The idea at TPAC, if I recall
>>> correctly, was to allow for multiple encodings in the structure of the
>>> parameters, but to only allow one encoding in WebRTC 1.0 (simulcast could
>>> be addressed in future versions, but the structure would be there).
>>>
>>> However, there was less discussion and consensus around multiple
>>> encodings than there was of the parameters model in general, and recently
>>> on the list there has been doubt whether we should put it in there.
>>>
>>> The alternative (call it B) would be to do flatten the structure like so:
>>>
>>> dictionary RtpParameters {
>>>   bool active;
>>>   float priority;
>>> }
>>>
>>> // No RtpEncodingParameters dictionary
>>>
>>>
>>> And then later when we decide that we do need multiple encodings, try
>>> and add it in a backwards-compatible way.  One way suggested to me would be
>>> do add it like this later:
>>>
>>> dictionary RtpParameters {
>>>   // These values are shared between all encodings, unless overidden by
>>> ".encodings".
>>>   bool active;
>>>   float priority;
>>>   sequence<RtpEncodingParameters> encodings;
>>> }
>>>
>>> dictionary RtpEncodingParameters {
>>>   // These values override the values shared by all encodings
>>>   bool active;
>>>   float priority;
>>> }
>>>
>>> So, which shall it be?  Put in room now for expansion later, or simplify
>>> a bit and figure out expansion later?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>