- From: Justin Uberti <juberti@google.com>
- Date: Tue, 25 Aug 2015 17:56:31 -0700
- To: Peter Thatcher <pthatcher@google.com>
- Cc: Randell Jesup <randell-ietf@jesup.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOJ7v-2pChVufLijUGNo68S7qq-OYTvUquLq_r+LaOq+k-n28A@mail.gmail.com>
For ORTC, we came to the conclusion that any adjustments to the input to the RtpSender (e.g. framerate clamping) ought to be performed on the input MediaStreamTrack. The scale attributes are just for scalable encoding/simulcast, so that multiple encodings can be created from a single input MST. On Mon, Aug 24, 2015 at 3:01 PM, Peter Thatcher <pthatcher@google.com> wrote: > 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 >> >> >
Received on Wednesday, 26 August 2015 00:57:20 UTC