Re: I have created a PR for RtpEncodingParameters.maxBitrate

On 19/07/15 04:44, Randell Jesup wrote:
> 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.

Before going too deep into defining a lot of knobs, it would be really 
good to get a proper definition of "bitrate". Averaged, over what time 
period? Including or excluding (what) headers? Leaky bucket?

Also, would there be any interaction between bitrate and priority, for 
priority it is said

"When there is limited bandwidth available to a PeerConnection, higher 
prioirty encodings will be sent with more bandwidth, and lower priority 
encodings will be sent with less bandwidth."

Seems there could be conflicts here (e.g if a high minimum bitrate is 
combined with a low priority for a stream). I had in the past understood 
"priority" as only affecting the DSCP markings, and not being involved 
in bitrate decisions made by the UA.




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

Received on Monday, 20 July 2015 14:26:13 UTC