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: Sun, 19 Jul 2015 00:43:24 -0400
Message-ID: <55AB2AEC.8090302@jesup.org>
To: public-webrtc@w3.org
On 7/18/2015 11:07 PM, Silvia Pfeiffer wrote:
> On Sun, Jul 19, 2015 at 12:41 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
>> 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.

Mostly I agree - and most apps shouldn't be messing with these. However, 
this isn't always the case. The app does have some control over the 
resolution/framerate, and also it may want to limit the bandwidth used 
by (for example) screensharing (or limit the bandwidth used for a 
thumbnail talking-head that's being layered on top of a screenshare at 
the receiving end).

I will note this is a *common* request.  And apps are currently editing 
(Chrome) SDPs to adjust max bitrates.

We've recently reduced the need to do this by (in Firefox) making the 
upper & lower bandwidth bounds depend on the resolution/framerate of the 
input video - throwing 2Mbps at a QQVGA (160x120) stream is pretty silly 
- in fact, 2Mbps is slight overkill even for VGA.  and 2Mbps is way too 
low for an HD 1080 stream, let alone a full-resolution screenshare of a 
Retina screen.

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

Sure, congestion may well keep you below the max - max is just "don't go 
over this even if you seem to have the bandwidth".

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

That requires unified congestion control - and for many use-cases, 
unified across multiple PeerConnections.  In non-bundle in theory the 
RTP destinations can be different, and it's possible routers will apply 
different constrictions per stream (especially if the DSCP marks are 
different).

I would imagine that the real thing you'd want is to *not* give equal 
amounts to multiple video channels in a bundle, and that by default 
they'd get equal shares if resolutions are equal.  (I.e. I care more 
about this one than that).

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

Maybe so.   But this is a different request than Maximum bitrate, you're 
talking about interacting with the parceling out of the available bits 
(when we don't have enough to hit max on all streams).


-- 
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 04:44:10 UTC

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