W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2015

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

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 8 Jun 2015 16:10:23 -0700
Message-ID: <CAJrXDUFCm_rWsHkT-WBDm-jNSxmGjs0wnzi7mNbtJ1nb-RHi=A@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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?
>
>
>
>
>
>
>
Received on Monday, 8 June 2015 23:11:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC