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

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
> }];
>
>
>