W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2016

Re: maxHeight and maxWidth

From: Cullen Jennings <fluffy@iii.ca>
Date: Sun, 14 Feb 2016 10:01:04 -0700
Cc: Peter Thatcher <pthatcher@google.com>, Randell Jesup <randell-ietf@jesup.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <934AC00F-817F-47EA-AD0F-593C3D234F03@iii.ca>
To: Adam Roach <adam@nostrum.com>

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. 

We would use this for spark and other things. 


> 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
Received on Sunday, 14 February 2016 17:01:30 UTC

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