Re: I have created a PR for RtpEncodingParameters.maxBitrate

On Sun, Jul 19, 2015 at 12:41 PM, Randell Jesup <randell-ietf@jesup.org> 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

Unless you know the available bandwidth overall for the device and the
minimum bandwidth necessary to encode a stream of data, these are
actually pretty useless to a developer.

For example, the min bitrate required to send audio or video is codec
and resolution specific and the browser seems in a much better
position than the developer to know this boundary.

Similarly, the max bitrate is really dependent on the available
bandwidth to the device and may fluctuate. So, the browser should be
in a much better position to know this, too (despite Chrome currently
randomly choosing 2Mbps per video stream).

As a developer, I would really like to see controls that are relative
to these boundaries, not absolute numbers. E.g. I'd like to tell each
outgoing/incoming video stream to use no more than 25% of my available
bandwidth - which would then adapt to the available bandwidth (looks
like RTP would then also need to negotiate the minimum of the two).
Then, e.g., the data channel should use no more than 40% of my
available bandwidth - since it's bursty, it can take a bit more.

In any case, absolute numbers are always going to be wrong and
suboptimal, so I'd much prefer going with relative numbers.

My 2c worth.

Cheers,
Silvia.

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

Received on Sunday, 19 July 2015 03:08:18 UTC