Re: I have created a PR for RtpEncodingParameters.maxBitrate

I updated the PR with a TODO to get a definition of bitrate.  I think we
can merge the PR with the knob with such a TODO.  We can, for example,
start implementing the knob, even if we have to tweak the meaning later to
match a different definition of bitrate.

On Mon, Jul 20, 2015 at 7:25 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

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