Re: maxHeight and maxWidth

While thinking about this so more, I thought of another difficulty: if
resolution is degraded, should that degradation happen before or after the
max?

In your use case with two layers (1 full, 1 max of 90 pixels tall), what
happens when the RtpSender degrades the resolution?  Let's say it degrades
a video frame an original height of 360 pixels down to a height of 180
pixels.  Clearly, the full layer is now 180 pixels high.  But what should
it do with the max-height-90-pixel layer be?  Should it become 45 pixels
tall or stay 90 pixels?   If it should stay 90, then what happens if the
video further degrades down to 1/4 of the original size, such that the full
layer is also 90 pixels high?  Would they both be 90?


On Wed, Feb 10, 2016 at 11:28 AM, Adam Roach <adam@nostrum.com> wrote:

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