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

A few comments on your example:

- Your example of priority (0.5 = "half the resources") matches the
proposal.
- Your example of scale (1 = "don't downsample") matches the proposal.
- Your example of framerate isn't in the proposal.  I thought about adding
it, but decided that is was sufficient (and more simple) for the use cases
to allow limiting the framerate with the Track instead of the RtpSender.
 If the app just wants the framerate to stay very high, how is that
different from having "bias: 'framerate'"?
- I also have no idea what the quality metric is.  There was a TODO in the
proposal :).

I apologize for the curt "what's the use case" response.  Perhaps I'll
provide my own: sign language would prefer a 30fps over quality.  But,
again, wouldn't that use case be covered by saying "bias: framerate"?


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.


On Wed, Feb 19, 2014 at 9:53 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 19 February 2014 07:15, Chris Wendt <chris-w3c@chriswendt.net> wrote:
> > I don’t believe there shouldn’t be aspirations of having a priority or
> > frame-rate vs quality parameters meaning anything explicit, with any
> > expected outcome other than a “preference" that guides the underlying
> > implementation to “try" to conform to.
>
> That's a reasonable starting point.  If this were:
>
> priority: 0.5,   // give half the resources of something with priority 1
> preferences: {
>   scale: 1, // don't downsample if you please
>   framerate: 30, // keep the frame rate here
>   quality: // I have no idea what metric we should be using here
>             // (0..1 where 0 = 0 bits and 1 = all the bits?)
> }
>