- From: Peter Thatcher <pthatcher@google.com>
- Date: Tue, 16 Feb 2016 19:00:03 -0800
- To: Jan-Ivar Bruaroey <jib@mozilla.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAJrXDUE2s633piZh4DfuhNvX6+V7OpUj+ePwJtxo4PxLL+Jztg@mail.gmail.com>
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