W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2015

Re: I have created a PR for RtpEncodingParameters.maxBitrate

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 20 Jul 2015 09:19:33 +1000
Message-ID: <CAHp8n2=O3e2QknQBwkDGyJnRXdzkPiQRczSf0-MzU4L-c__J4A@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Cc: public-webrtc <public-webrtc@w3.org>
On 20 Jul 2015 4:13 am, "Randell Jesup" <randell-ietf@jesup.org> wrote:

>>>> 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
>>> we don't have enough to hit max on all streams).
>> In a perfect world, the bitrate that I would choose for encoding a
>> video stream would be limited by the bitrate that I get for
>> transmitting the stream (including all the bandwidth that the network
>> intermediaries allow me), wouldn't it? If I encode at a higher bitrate
>> than I can send, then I'm basically screwed. If I encode at lower
>> bitrate, then I create a worse quality stream than would be possible.
>> This applies as much to the individual channels in a bundle as it
>> applies to the whole bundle.
> Well.... it's more complex than that (for lower bitrates).  There are
other reasons to restrict bitrate.
> One would be knowing (in the app) that the receiver is downscaling a lot
at the moment.
> Another would be selective-forwarding (without layered encoding or
simulcast): the application may be told by the server to restrict a
specific stream to max NNNNNbps because of the congestion limits forwarding
it to a specific recipient.
> Another would be sending it to a server that's recording it without
reencoding (basically decrypted--but-not-decoded-stream-recording, which
can work quite well for some usecases).
> Another would be some of the fancier ideas for partial-mesh conferences
(where someone forwards to others).

Fair enough. Though even in these situations I'd much prefer saying: don't
encode at higher that x% of my available internet bandwidth so I don't
start losing some of my other streams.

> So, there are reasons for max, and max in bps not some % of what the
browser thinks should be the normal max.

I'd suggest both.

BTW: I like the idea of specifying it as a percentage of what the browser
thinks is available rather than of the available send / receive bandwidth.
Adjustments can then be made as the browser discovers a new bandwidth

>> Anyway - I actually do want a parameter to set limits on maximum
>> bandwidth (not so much on minimum though). I want it to be a
>> percentage though, because that allows me to provide priority hints to
>> the browser.
> I'm not against %'ages, but would want to see a little more reasoning
about what it would mean.  Would being able to read back the current
min/max stand in for a % setting?  (Read in max, multiply and set new max)

Would every time a user asks for a change imply that a new negotiation has
to be kicked off? If so, isn't providing a percentage much more automatic
and less disruptive? The encoder can make the changes without having to

Received on Sunday, 19 July 2015 23:20:05 UTC

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