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

Re: maxHeight and maxWidth

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 17 Feb 2016 12:15:43 -0800
Message-ID: <CAJrXDUG7cB-HC4nZ-0nbZ_w=f+jKmOVqxYWLffAG7kgV7uo5Fg@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Feb 17, 2016 at 10:36 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 17/02/16 18:47, Jan-Ivar Bruaroey wrote:
> > On 2/17/16 12:36 PM, Peter Thatcher wrote:
> >> The original thread was about both screencasts and rotating cameras,
> >> and I've mostly been focusing on the screencasting case (trying to
> >> figure that out before moving on to rotation).
> >>
> >> But, actually, I have a question for you about getUserMedia:
> >>
> >> If I specify an exact height of 90 pixels (min and max are 90) and the
> >> camera can't open that small, what will an implementation of
> >> getUserMedia be expected to do?  Will it scale the camera's input in
> >> order to get that exact height, or will it just say "nope"?  Or is it
> >> implementation dependent?
> >
> > I believe Chrome will rescale it to whatever you want, whereas Firefox
> > will fail with OverconstrainedError, reflecting the fact that no camera
> > on the machine has a native 160x90 mode. Both are to spec btw, but which
> > one honors the intent of the spec?
>
> I think it was Cullen who at a call once said that he was fine with the
> UA removing data, but not inventing. That has stuck with me since, so it
> would be OK to downscale resolution (or frame rate) to meet what the app
> wants, but not the other way around.
>
>
If upscaling is not allowed, then I it's impossible to meet a requirement
of "must be exactly 90 pixels in height".  ​



> But I agree, the spec is not clear on what should be done.
>
> >
> > See my other post right now about discovery and arbitrary scaling being
> > mutually exclusive.
> >
> > .: Jan-Ivar :.
> >
>
>
Received on Wednesday, 17 February 2016 20:16:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:14 UTC