Re: maxHeight and maxWidth

On Fri, Feb 12, 2016 at 2:45 PM, Adam Roach <adam@nostrum.com> wrote:

> On 2/12/16 16:10, Peter Thatcher wrote:
>
> ​ But seeing that code does give me an idea for something even better; add
> an event to a video track: onresolutionchanged.  Then, whenever the video
> track's resolution changes, the Javascript can reset the scale:
>
> track.onresolutionchanged = function(evt) {
>   var params = sender.getParameters();
>   params.encodings[1].scaleResolutionDownBy = evt.height / 90;
>   sender.setParameters(params);
> }
>
> ​It has the downside that a frame or two of the old scale might escape.
>
>
> Yeah, I almost proposed this as an alternative, but identified the race
> and found it to be unacceptable.
>
> Doing this pushes the problem down the constituency priority chain from
> implementors all the way to authors and users. And, make no mistake here:
> you're proposing user-visible glitches. This is exactly the wrong direction.
>

It's a pause of few frames on a 90-pixel tall video feed when a sceencast
is resized or a camera is rotated.  I'm also not a fan of glitches, but
that's a very minor glitch.  It's doubtful anyone will notice on a 90-pixel
tall video (who is going to be constantly looking at a 90-pixel tall
screencast, anyway?), and p
auses are common when resizing screencasts anyway, since you
​typically suddenly have a big key frame, and pauses are also common for
rotation when CVO isn't available (and I'm assuming the "I can only handle
90 pixels tall" receiver can't handle CVO).  ​ So, not much more glitchy
than normal screencast/non-CVO-rotation territory.

If we're going to worry about glitches, we should worry about what happens
to the "I can only handle 90 pixels tall" receiver when the screencast goes
below 90 pixels, because scaling down can't save you there, and the video
will suddenly stop, or worse.

If you want glitch-free scale down and scale up, I believe we already have
the controls you need: clone the track, apply constraints, and make 2
RtpSenders.  It's not as convenient as using encoding parameters but it
works.
​


>
> I wonder if there's some way to hook into Media Source Extensions that
> would allow the apps to perform these kinds of changes on a frame-exact
> basis. Anyone here sufficiently familiar with that spec to be able to
> answer?
>
> /a
>
​