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

RE: maxHeight and maxWidth

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Wed, 17 Feb 2016 01:03:55 +0000
To: Jan-Ivar Bruaroey <jib@mozilla.com>, Peter Thatcher <pthatcher@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <BLUPR03MB149CEA04D9021293AC1076BECAE0@BLUPR03MB149.namprd03.prod.outlook.com>
Comments below.

From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
Sent: Tuesday, February 16, 2016 3:27 PM
To: Peter Thatcher <pthatcher@google.com>
Cc: public-webrtc@w3.org
Subject: Re: maxHeight and maxWidth

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.

[BA] Just for my own sanity – are we talking about scaleResolutionDownToHeight/Width OR scaleResolutionDownBy *and* maxHeight/maxWidth OR just maxHeight/maxWidth?


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.
[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), while supporting a minimal set of functionality useful for *both* simulcast and scalable video coding (SVC) (and combinations of the two).  While I am sympathetic to the somewhat unique requirements of screen sharing, it is also important not to lose sight of this bigger picture.

If that's not happening, then I find scaleResolutionDownBy and maxFramerate useful outside of simulcast.

.: Jan-Ivar :.

[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?  That seems like a classic triumph of hope over experience ☺

Bernard “Baseless Optimism Usually Results in Disappointment” Aboba
Received on Wednesday, 17 February 2016 01:04:30 UTC

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