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

Sending Simulcast can be handled by track cloning (with different constraints). Receiving can also be supported either with different SSRCs (most SFUs do it that way) or a single one.
________________________________
From: Eric Rescorla<mailto:ekr@rtfm.com>
Sent: ‎6/‎8/‎2015 4:37 PM
To: Peter Thatcher<mailto:pthatcher@google.com>
Cc: public-webrtc@w3.org<mailto:public-webrtc@w3.org>
Subject: 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<mailto: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<mailto: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?