Re: A Big Proposal: A way to control quality/resolution/framreate/simulcast/layering with RtpSender

On 19 February 2014 13:33, Peter Thatcher <pthatcher@google.com> wrote:
> So, if I may start a TODO list here, I would include:
> 1.  Debate "framerate: 30" vs "bias: framerate"
> 2.  Figure out what "quality" means numerically.

Sounds like a good place to start.

I really only threw the example down as a way to highlight something
closer to what Chris suggested, which I think was closer to what I
think is reasonable.  I intentionally stole as much as possible from
your stuff, because I think that it's on the right track.

Maybe there's a simple way to deal with this:
1. Priority determines bandwidth allocation (and might have secondary
effects on things like DSCP, but let's pretend that's not going to
happen; I'm not going to have to try very hard on that count).
2. Everything else is input to the browser in making the
spatial/temporal/quality tradeoff.

On the latter, here's a strawman:

All "preference" values are between 0 and 1.  0 = don't give me media,
1 = please try to retain what the MediaStreamTrack is providing you
exactly, and anything in between is degrees of the same.  Unless we
are doing raw video, we will never make it to 1 on the quality axis,
but we might make it on the other axes, but otherwise these can be
treated fairly similarly at the abstract level.

That forms a three dimensional space.  For any given bandwidth, there
is a surface in that three-dimensional space with [0, 0, 0] on the
opposite side to [1,1,1].  If the surface passes through [1,1,1], or
passes the other side of it from the origin, that means it is possible
to losslessly transmit the video (and we are probably searching for
work).

Otherwise, there are three modes based on what is provided by the
application:  If an application provides three values, the browser's
challenge is to find point on that space that minimizes the distance
to the application-provided point.  If the application provides two
values, the browser either finds the point of minimum distance to the
implied line, or the point of intersection between the surface and the
line.  If there is only a single value provided, then it is the point
on the intersection between the surface and the implied plane that is
closest to [1,1,1].

Given a definition of each of these axes, I would expect that browsers
would be able to implement something that approximates consistent,
subject of course to variations in bandwidth availability testing and
other constraints.

This also generalizes to more dimensions, but I'd caution against that.

Received on Wednesday, 19 February 2014 22:17:18 UTC