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

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