maxHeight and maxWidth

On 10/12/15 10:37, Peter Thatcher wrote:
> ​ My point was that if you think we should have ".maxWidth" and 
> ".maxHeight" in RTCRtpEncodingParameters, that's a separate proposal. 
>   So, if you want it, please propose it.

This didn't seem particularly important at the time, but we've gotten 
some implementor feedback that indicates otherwise.

Specifically, we've heard from implementors that the use of the current 
proposed (sole) control for resizing simulcast streams is problematic in 
the face of streams that can change size (such as captured windows, or 
rotating cameras on mobile devices).

The scenario under consideration is one in which each media source 
generates two streams: one full-size, and one which must be exactly 90 
pixels tall. These are being sent to a media switch, which has no 
ability to decode and re-encode streams. Some of the recipients 
(non-web-browsers) do not have the ability to resize incoming streams.

In the optimal (and admittedly typical) case, would be possible to do 
something like this:

   params.encodings[1].scaleResolutionDownBy = 
videoTrack.getSettings().height / 90;

Where this falls apart is when the height of the video track *changes*.

By contrast, if they could simply do something like:

   params.encodings[1].maxHeight = 90;

Then the problem goes away.

This seems relatively straightforward to spec out, and -- given that we 
see real implementor need for it -- I think it makes sense to go ahead 
and add it at this point.

So, what are the arguments against maxHeight and maxWidth?

/a