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

maxFramerate can be accomplished with a gUM constraint, so I don't think
it's needed on the RtpSender.

Also, I should mention that I didn't include "minQuality" from ORTC, since
I didn't think we'd ever be able to resolve what "quality" means in the 1.0
timeframe, even if it's relative quality.



On Mon, Aug 24, 2015 at 12:16 PM, Randell Jesup <randell-ietf@jesup.org>
wrote:

> 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>
> 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
>
>