W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2015

Re: I have created a PR for RtpEncodingParameters.maxBitrate

From: Randell Jesup <randell-ietf@jesup.org>
Date: Mon, 20 Jul 2015 04:32:51 -0400
Message-ID: <55ACB233.8030703@jesup.org>
To: public-webrtc@w3.org
On 7/19/2015 7:19 PM, Silvia Pfeiffer wrote:
>
> On 20 Jul 2015 4:13 am, "Randell Jesup" <randell-ietf@jesup.org 
> <mailto:randell-ietf@jesup.org>> wrote:
>
> > Well.... it's more complex than that (for lower bitrates). There are 
> other reasons to restrict bitrate.
>
[snip]
>
> Fair enough. Though even in these situations I'd much prefer saying: 
> don't encode at higher that x% of my available internet bandwidth so I 
> don't start losing some of my other streams.
>

% of available != % of internet bandwidth.  If "some of my other 
streams" is streams not included in this 5-tuple grouping or this 
peerconnection, then it sounds like you're trying to set the 
peerconnection at <100% of available, which is not a very usable case.  
I.e. % of what?

If % is of the streams in this peerconnection/5-tuple, then it gets 
problematic when %'s don't add up to 100%, or if one of the streams 
doesn't use it's allocation.

I think you need to be more specific about what you want to ask for, and 
what you expect to happen.  With that, perhaps % makes sense, but I need 
to see the description/request.

> > So, there are reasons for max, and max in bps not some % of what the 
> browser thinks should be the normal max.
>
> I'd suggest both.
>
> BTW: I like the idea of specifying it as a percentage of what the 
> browser thinks is available rather than of the available send / 
> receive bandwidth. Adjustments can then be made as the browser 
> discovers a new bandwidth situation.
>

So, this is talking to prioritization of bit allocation, not limits of 
bit allocation.  Which is a valid case, though by default we should 
assume the UA implements a reasonable bit allocation mechanism, and some 
sort of proportionality to the maximum-minimum (after minimum's are 
satisfied) would be obvious.  I.e. every stream gets its minimum.  Then 
extra bits are allocated proportionally based on max-min for each stream.

Inputs to that allocation are reasonable to suggest, and % might be 
reasonable, but it's pretty separate from maximums in most/many cases.  
If you specify 50% of available, and your camera provides VGA max, what 
happens when you're on a 100Mbps link?  Sending 50Mbps for VGA is not 
very useful...

> >
> >> Anyway - I actually do want a parameter to set limits on maximum
> >> bandwidth (not so much on minimum though). I want it to be a
> >> percentage though, because that allows me to provide priority hints to
> >> the browser.
> >
> >
> > I'm not against %'ages, but would want to see a little more 
> reasoning about what it would mean.  Would being able to read back the 
> current min/max stand in for a % setting?  (Read in max, multiply and 
> set new max)
>
> Would every time a user asks for a change imply that a new negotiation 
> has to be kicked off? If so, isn't providing a percentage much more 
> automatic and less disruptive? The encoder can make the changes 
> without having to renegotiate.
>

None of this should be kicking off renegotiation.  This is about encoder 
settings; SDP bandwidth info is amount-I'm-willing-to-receive....

-- 
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 Monday, 20 July 2015 08:33:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC