Re: maxHeight and maxWidth

On 2/16/16 8:03 PM, Bernard Aboba wrote:
> [BA] I believe that the original argument for RTCRtpEncodingParameter 
> attributes such as scaleFramerateDownBy and scaleResolutionDownBy was 
> to avoid re-introducing the constraints language (and associated issues),

This seems like a misunderstanding, since constraints are necessary only 
to arbitrate competing interests, and is overkill otherwise. If you just 
want set(width, height) to always produce width x height, then there's 
hardly a need for something as complicated as the applyConstraints model.

> *[BA] If constraints implementations cannot in practice provide a 
> track with the desired characteristics, is it reasonable to expect 
> that an encoder implementation will do better?*

Ability isn't at issue. Design intent is.

Is the purpose of constraints to rescale camera output into whatever the 
application wants?

Constraints at their (complex) core grew out of needing to manage not 
getting exactly what you want, and to let users interrogate inherent 
capabilities instead, making getUserMedia a discovery API.

But if for every width x height you pass in, you get exactly width x 
height back, then you've discovered nothing.

Arbitrary scaling and discovery are mutually exclusive in the gUM API as 
written (something Chrome will find out once it tries to implement 
fitness distance).

The gUM API is also giant overkill for arbitrary scaling.

.: Jan-Ivar :.