Re: maxHeight and maxWidth

On 10/02/16 20:31, Adam Roach 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?

(Contributor hat:)

We've introduced maxBitrate and maxFramerate in the 
RTCRtpEncodingParameters dictionary, so adding maxHeight and maxWidth 
would not look that strange IMO.

Further, we already have to have text (if any more is needed - I'm not 
sure) explaining the relation between a track's frameRate 
constraint/setting and maxFramerate of the EncodingParameters, so doing 
the same for maxWidth/Height vs. the track's width/height constraint 
should be straightforward.

The odd bird would then actually be "scaleResolutionBy". While what it 
means when the track is constrained to a narrow range regarding width 
height is clear, I think we may need some more text on what happens when 
the input track is unconstrained (and can vary a lot).

We also need to clarify what would happen if both maxWidth/Height and 
scaleResolutionBy are set (and are contradicting in some way).

>
> /a

Received on Friday, 12 February 2016 12:59:54 UTC