- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 20 Jul 2015 19:27:08 +1000
- To: Randell Jesup <randell-ietf@jesup.org>
- Cc: public-webrtc <public-webrtc@w3.org>
On Mon, Jul 20, 2015 at 6:32 PM, Randell Jesup <randell-ietf@jesup.org> wrote: > Inputs to that allocation are reasonable to suggest, and % might be > reasonable, but it's pretty separate from maximums in most/many cases. If > you specify 50% of available, and your camera provides VGA max, what happens > when you're on a 100Mbps link? Sending 50Mbps for VGA is not very useful... Right, you wouldn't go with something that is larger than what the browser needs to send full quality. In this example, let's say it calculated that 1.5Mbps is sufficient to provide full quality VGA. Then giving it 50% means that it will only go below 1.5Mbps when the available bandwidth goes below 3Mbps. >>> 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. > > > None of this should be kicking off renegotiation. This is about encoder > settings; SDP bandwidth info is amount-I'm-willing-to-receive.... Getting current min/max (particularly max) would work then, I guess. Cheers, Silvia.
Received on Monday, 20 July 2015 09:27:55 UTC