Re: maxHeight and maxWidth

Not exactly.  We decided that we wanted something better for simulcast than
multiple RtpSenders, at least for the main use cases of simulcast.  And
even though we have agreed to set of parameters that covers easily 90% of
simulcast scenarios, we did not decide that we would put in all the
parameters that anyone would ever need to cover all possible use cases.
Nor does our decision prevent someone from using multiple RtpSenders for
more obscure use cases (such as the one you have presented, which isn't
even solved with maxHeight/maxWidth anyway).

In fact, quite the opposite: we decided that for 1.0, we would target a
limited set of controls and avoid making it too complex.   And we talked
many times about maxWidth/maxHeight and its flaws, and it was, while
perhaps not "rejected", were never accepted either.

On Fri, Feb 12, 2016 at 7:20 PM, Adam Roach <abr@mozilla.com> wrote:

> On 2/12/16 19:23, Bernard Aboba wrote:
>
> On Feb 12, 2016, at 3:15 PM, Peter Thatcher < <pthatcher@google.com>
> pthatcher@google.com> wrote:
>
> If you want glitch-free scale down and scale up, I believe we already have
> the controls you need: clone the track, apply constraints, and make 2
> RtpSenders.  It's not as convenient as using encoding parameters but it
> works.
>
>
> [BA] That's what bugs me about this - the only reason to add another
> attribute to RTCRtpEncodingParameters is if it enables developers to do
> something they cannot already accomplish with track cloning.
>
> But so far, we haven't considered a scenario that cannot be accomplished
> with what we already have.
>
>
> The clone/constrain/send solution has the same flaws in this case as it
> does in the general case. We already rejected that approach.
>
> --
> Adam Roach
> Principal Platform Engineer
> Office of the CTO
>