Re: Al PR for adding various fields to RtpParameters and RtpEncodingParameters

On 8/22/2015 3:23 AM, Peter Thatcher wrote:
> I have created PR 273 (https://github.com/w3c/webrtc-pc/pull/273). It 
> has not had much discussion on the list.  I created it to start the 
> discussion.  I hope we can talk about it f2f in a few weeks.

> And it also proposes some configurable fields:
>
> encodings
> resolutionScale
> framerateScale
> framerateBias

Thanks - I was about to submit a PR for these, but you beat me to it. 
;-)  Seriously, thanks for checking making sure all these had PRs.

I used the same general interface as ORTC, but renamed and rewrote the 
description.  I use resolutionDivideBy/framerateDivideBy, as to me 
"blahScale = 2.0" reads as "should multiply blah by 2.0".   Also I added 
a stipulation that it must be >= 1.0 (i.e. no upscale/up-framerate) (or 
rather, that values below 1.0 will not cause upscaling).  In addition, I 
specified rounding down.

I also added framerateMax (floating, not integer, so I used double).  
And also the time period for framerate measurement is unspecified; I 
specified 1 second.

eg:

           <dt>double resolutionDivideBy</dt>
           <dd>
             <p> Value the input resolution should be divided by for encoding.
             Example: 1.0 = full resolution, 2.0 = one half of the full
             resolution, rounded down, in both dimensions.  Values below 1.0 will
     not result in any scaling-up of the source.
             </p>
           </dd>
           <dt>double framerateMax</dt>
           <dd>
             <p> Value the input framerate should not exceed, measured over
             a time period of 1 second.  The encoding should attempt to use
             a regular pattern of frame drops to reduce input framerate to
             framerateMax if the input rate exceeds framerateMax.
             </p>
           </dd>
           <dt>double framerateDivideBy</dt>
           <dd>
             <p> Value the input framerate should be divided by for
             encoding, measured over a time period of 1 second.  The
             encoding should attempt to use a regular pattern of frame drops
             to reduce input framerate to the target rate.  Values below 1.0
     will not result in any increase in framerate
     </p>
           </dd>

>
> If you want to see the details of what they mean, look at the PR. If 
> you want to see the inspiration for them, see 
> http://ortc.org/wp-content/uploads/2015/06/ortc.html. If you'd like to 
> discuss one in particular, that's what the list and the upcoming f2f 
> meeting are for :).

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam