Re: I have created a PR for RtpEncodingParameters.maxBitrate

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
(when
>>> 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
situation.

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

Cheers,
Silvia.