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

Hi Peter,

I’m thinking about a slightly different view of the parameters.
Traditionally, video encoders usually deal with a 2-dimentional trade off between picture quality and higher temporal framerate;  lower framerate with better intra picture quality vs. higher framerate and better motion with reduced overall picture quality.
Including resolution in the mix adds a 3rd dimension, making parameterizing the priority of one over the other less straight forward.

What about the approach where we consider first resolution/scale and picture quality as an isolated parametric tradeoff or bias, because they relate to overall visual quality of frames.  Then having a second bias for overall picture quality vs. temporal framerate.

So perhaps something like this:
double priority; // remains bit allocation for overall stream
double scale; // max scale allowed? (sort of a separate related question of whether this is a max scale or whether you can increase the resolution above the set scale)
double maxBitrate;  // max bitrate
double maxFramerate; // max framerate
double pictureQualityBias;  // 0.0 to 1.0 for bias toward hitting max resolution vs. max picture quality at lower resolution per frame
double temporalBias;  // 0.0 to 1.0 to favor hitting max framerate

-Chris



> 
>   // New Fields
>   // The higher the value, the more the bits will be given to each
>   // as available bandwidth goes up.  Default is 1.0.
>   double priority;
> 
>   // Do this scale of the input resolution, or die trying.
>   // 1.0 = full resolution.  Default is unconstrained.
>   double scale;  
> 
>   // Ramp up resolution/quality/framerate until this bitrate.
>   // Summed when using dependent layers.
>   double maxBitrate;  
> 
>   // Ramp up resolution/quality/framerate until this quality.
>   double maxQuality;
> 
>   // Never send less than this quality.
>   double minQuality;  
> 
>   // What to give more bits to, if available.  
>   // Perhaps make it an enum.
>   DOMString bias; // "resolution" or "framerate"
> 
>   // If false, don't send any media right now.
>   // Disable is different than omitting the encoding; it can keep 
>   // resources available to re-enable more quickly than re-adding.
>   // Plus, it still sends RTCP.
>   // Default is active.
>   bool active;