Re: I have created a PR for RtpEncodingParameters.maxBitrate

On 7/19/2015 4:12 AM, Silvia Pfeiffer wrote:
> Preferably, as a developer, I don't want to have to deal with setting
> a limit at all, because the browser should have better information
> about all the facts relevant to choosing a bitrate: the CPU used for
> encoding and decoding, the bandwidth available for sending and
> receiving, the bandwidth available for sending and receiving at the
> other end, the number of dropped packets. I firmly believe that a
> request to set bitrate manually by developers is based on observed
> misbehaviour of browsers that do a bad job at picking an adequate
> bitrate, which is a shame.

Certainly a main driver right now is the 2Mbps default in Chrome (and 
Firefox, but they haven't been able to change it in the SDP with 
firefox, only about:config vars.  Per previous message, the defaults in 
Firefox are better now in 41.)  And most developers won't touch this, 
especially once the browsers are adaptive to resolution & frame rate 
(and codec once vp9 is mainstream).

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

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

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

-- 
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 18:11:07 UTC