Re: maxHeight and maxWidth

On Sun, Feb 14, 2016 at 9:01 AM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> I think we should add this. It is very easy to implement. It is very
> intuitive for JS developers to use. And it is what developers usually want
> when they are trying to produce video that fills a fixed size portion of
> display where it is rendered.
> ​  ​
>
It works correctly across things like video resizes with no glitches. It
> also makes it easier to gateway to things that don't have the ability to
> deal with video that changes size on the fly.


​W
hat about resolution degradation or a screencast resizing down below the
set max?  How
​are these things that can't handle video size changes going to
 handle the situations when the video is smaller than the expected fixed
size?  ​


>
> We would use this for spark and other things.
>

For those of us not familiar with spark, could you please provide more
detail about why maxHeight is needed?  Is it the use case of "only 90
pixels tall" that originated this thread, or is a different one?​
​


>
> > On Feb 10, 2016, at 12:28 PM, 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
>
>