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

Re: maxHeight and maxWidth

From: Peter Thatcher <pthatcher@google.com>
Date: Tue, 16 Feb 2016 19:00:03 -0800
Message-ID: <CAJrXDUE2s633piZh4DfuhNvX6+V7OpUj+ePwJtxo4PxLL+Jztg@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
This was brought up specifically in the context of screencasts.  I assume a
screencast track implementation could easily meet arbitrary min/max
resolution constraints (by scaling).

On Tue, Feb 16, 2016 at 3:26 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> On 2/13/16 11:50 PM, Peter Thatcher wrote:
>
> ​I hope we can all remember that we are only considering
> scaleResolutionDownToHeight/Width for the encoding parameters *for
> simulcast scenarios*.  If simulcast isn't part of the scenario, then
> there's no need for these (or maxFramerate, or scaleResolutionDownBy,
> etc).  And most app developers never deal with simulcast.   Anything we add
> for simulcast is already well in the realm of an advanced use case.
>
>
> Given the years the Media Capture and Streams WG spent defining an overly
> complex constraints language, I find the repeated assumption in this thread
> that a track can be constrained to any arbitrary size and frame rate,
> amusing.
>
> If it were true, it would offer amazing simplifications to that spec, like:
>
>   function fitnessDistance() { return 0 }; // = Whatever you want.
>
>   typedef  MediaTrackSettings MediaConstraintsSet; // no
> min|max|exact|ideal
>   typedef MediaConstraintsSet MediaTrackConstraints; // bye-bye advanced!
>
> Despite having sunk effort into implementing this already, I would
> personally welcome it. Just make up your collective minds.
>
> If that's not happening, then I find scaleResolutionDownBy and
> maxFramerate useful outside of simulcast.
>
> .: Jan-Ivar :.
>
>
Received on Wednesday, 17 February 2016 03:01:13 UTC

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