Re: I have created a PR for RtpEncodingParameters.maxBitrate

On 7/18/2015 6:10 AM, Harald Alvestrand wrote:
> On 07/18/2015 12:19 AM, Peter Thatcher wrote:
>> Here's the PR:
>>
>> https://github.com/w3c/webrtc-pc/pull/254
>>
>> Here's the diff:
>>
>> +
>> +          <dt>unsigned long maxBitrate</dt>
>> +          <dd>
>> +            <p>
>> +              Indicates the maximum bitrate that can used to send this
>> +              encoding.
>> +            </p>
>> +          </dd>
>>
>>
>> Question for the WG:  do we have consensus to add this?   I'm in 
>> favor of it :).
> Thanks!

I'm in favor, though I'm not sure this is sufficient.

> Looking through the current spec, there doesn't seem to be any other 
> bitrate limits specified, but we've chatted in the past about having 
> overall bitrate controls (at one point we had bitrate as a constraint 
> on createOffer, I think).
>
> Are there other places that need bitrate controls, and if so, how 
> should they interact?

So there are a couple of issues around bitrates, not all equally important:

* Control of the bitrate (max/min) for a specific stream
* Control of the starting bitrate for a specific stream
     Note this exposes some sharp points for applications to hurt 
themselves, though it may help some specific use-cases.  Congestion 
control should keep them from hurting things too much.  And limits could 
be applied (<50% max bitrate perhaps).
* Control of the current bitrate for a stream (within the bounds of 
congestion control)
* Control of the max total bitrate for all streams
    Not covered in the above.
* Control of max bitrate for DataChannels
Also:
* Monitoring the current bitrates
* What to do if the bitrate available goes below the minimum

Things I'd like to see addressed in addition to the PR above:
* Control of max total bitrate for all streams (action on the 
PeerConnection I'd presume)
* Control of max bitrate for DataChannels (note: as a whole) (again on 
the PeerConnection I'd presume, or maybe an action on any DataChannel 
object)
* Monitoring the current bitrates (to whatever extent it's not already 
covered in stats), particularly "instantaneous" bitrates.
* Perhaps some event on bitrate-too-low so the app can react (drop 
video, drop capture resolution, etc)
* Maybe min bitrate.

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