Re: Separate proposal on quality (was part of the "big proposal")

I think you are right, it’s probably too much of a rathole to define a particular priority semantic at this point, is it bitrate allocation percentage, is it send vs. not send based on available bandwidth, is it QoS parameters, is it a combination of everything, etc.

I think the implied meaning of priority and the value an application sets is probably ok for now based on the initially stated idea that these parameters are guidelines rather than portraying any particular expected behavior.


On Apr 17, 2014, at 3:25 PM, Peter Thatcher <pthatcher@google.com> wrote:

> 
> 
> 
> On Thu, Apr 17, 2014 at 9:40 AM, Chris Wendt <chris-w3c@chriswendt.net> wrote:
> I think it looks good.
> 
> I’m assuming you are implying the priority value is just a floating point relative scale ​. if you have an encoding at 1.0 priority and you add a new one with higher/lower priority you go up/down from 1.0.  Or it can be completely arbitrary float values as well? ​ ​Is there any quantitative priority scale implication?  1 vs 100 is “really big priority difference”, 1 vs 2 “not so big” or is it 1 vs 100 means the same as 1vs 2.
> 
> ​I was thinking of priorities as arbitrary relative value.  If I choose to make everything priority 200.0 in my application, then it's as if they were all priority 1.0, because they are the same relative to one another.  In other words, is everything is high priority, then nothing is high priority.  Is there any other option? 
> 
> ​That's a good question​ about what a big vs. small difference in priority means​ .  ​At first glance, I would say that a bigger priority difference means a bigger difference, but then we'll have to go define all of what that means (ie what does 5.0 audio and 1.0 main video and 0.2 thumbnail mean when bandwidth is really constrained?).    I admit I haven't thought a lot about that, and when I think a little bit about it, I realize that it can get complicated.  What do you think? 
> 
>  
> 
> -Chris
> 
> On Apr 15, 2014, at 3:18 PM, Peter Thatcher <pthatcher@google.com> wrote:
> 
>> Here's a simplified proposal for how to add quality control without getting too mixed up with quality (there will be a separate proposal for that).
>> 
>> dictionary RTCRtpEncodingParameters {
>>   // ... existing ssrc, codec, fec, rtx
>> 
>>   // The higher the value, the more the bits will be given to each
>> 
>> 
>> 
>> 
>>   // as available bandwidth goes up.  Default is 1.0.
>>   double priority;
>>   double maxBitrate;  
>>   double minQuality;
>>   // 1.0 == Bias toward framerate, 0.0 == Bias toward quality/resolution
>>   double framerateBias; 
>> 
>> 
>> 
>>   // Resolution/cropping/scaling is controlled by the input track!
>> }
>> Send a thumbnail along with regular size
>> var encodings1 = [
>>   ssrc: 1,
>>   priority: 1.0
>> }]
>> 
>> // Control the resolution and framerate with a different track and RtpSender.
>> var encodings2 = [{
>>   ssrc: 2,
>>   // Prioritize the thumbnail over the main video.
>>   priority: 10.0
>> }];
>> Sign Language 
>> (need high framerate, but don't get too bad of quality)
>> 
>> var encodings = [{
>>   minQuality: 0.2,
>>   framerateBias: 1.0
>> }];
>> Screencast
>> (High quality, framerate can be low)
>> var encodings = [{
>>   framerateBias: 0.0
>> }];
>> Remote Desktop
>> (High framerate, must not dowscale)
>> var encodings = [{
>>   framerateBias: 1.0
>> }];
>> Audio more important than video
>> var audioEncodings = [{
>>   priority: 10.0
>> }];
>> var videoEncodings = [{
>>   priority: 0.1
>> }];
>> Video more important than audio
>> var audioEncodings = [{
>>   priority: 0.1
>> }];
>> var videoEncodings = [{
>>   priority: 10.0
>> }];
>> 
>> Crank up the quality
>> var encodings = [{
>>   maxBitrate: 10000000
>> }];
>> 
>> Keep the bandwidth low
>> var encodings = [{
>>   maxBitrate: 100000
>> }];
>> 
> 
>