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

ok got you, that makes more sense, scale is not adjustable, it is a set parameter.  Sorry I misinterpreted.

Then I would just have a temporalBias that is picture quality vs. framerate.


On Feb 19, 2014, at 5:35 PM, Peter Thatcher <pthatcher@google.com> wrote:

> 
> 
> 
> On Wed, Feb 19, 2014 at 1:45 PM, Chris Wendt <chriswendt@hotmail.com> wrote:
> 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
> 
> ​Scale is there for the benefit of simulcast.  If you're not doing simulcast, you can pretty much ignore it.  And for the discussion of priority and bandwidth, scale doesn't really factor in.  Although... maybe someone can come up with another use case for it.
> 
> Max framerate can be controlled on the track instead of on the encoder/RtpSender, so it's not needed in these settings.
> 
> So, basically you want framerate vs. quality vs. resolution instead of framerate vs. resolution.  At one point while working on this design, I had something very similar, but decided against it because it added complexity and I didn't think it was that important to specify high resolution, low quality vs. low resolution, high quality.   But assuming you do want to specify that, would it be enough to say "bias: framerate|resolution|quality"?
> 
> ​
> 
>  
> 
> -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;
>> 
> 
>