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

Re: setting bandwidth

From: <piranna@gmail.com>
Date: Wed, 24 Jul 2013 15:17:22 +0200
Message-ID: <CAKfGGh06tEuE4BsDrtAn9U-1-Sy24oR+eZHBCwDs5hUJcqNhRw@mail.gmail.com>
To: Kiran Kumar <g.kiranreddy4u@gmail.com>
Cc: cowwoc <cowwoc@bbs.darktech.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Maybe the timer would be done in Javascript instead?

2013/7/24 Kiran Kumar <g.kiranreddy4u@gmail.com>:
> This seems to be nice Idea to send callbacks.
> But I suggest to add some timer on top of it. Like If the bandwidth drops
> below a certain minimum level, then it should wait for a predefined window
> time, if the bandwidth is still less than the minimum limit, then only it
> should send a call back.
> Because there are many network scenarios, that affects the bandwidth for a
> minute period of time, and recover to its normal state soon.
> Thanks,
> Kiran.
> On Wed, Jul 24, 2013 at 11:16 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>> On 24/07/2013 12:26 AM, Cullen Jennings (fluffy) wrote:
>>> On Jul 18, 2013, at 6:21 AM, Stefan Håkansson LK
>>> <stefan.lk.hakansson@ericsson.com> wrote:
>>>> 2. Setting BW for a MediaStreamTrack
>>>> ------------------------------------
>>>> Why: There are situations where a suitable start bit-rate can be known,
>>>> or guessed. If this knowledge could be used the perceived end-user
>>>> quality could be improved (since a higher quality is available from
>>>> start since there is no need to start at a really low bit-rate).
>>>> There are also situations where it could be beneficial if min and max
>>>> bit-rates to be used can be influenced.
>>>> * The app developer may know that below a certain bit-rate the quality
>>>> is so bad that the browser could stop sending it, and likewise there may
>>>> be knowledge about a bit-rate above which the quality does not improve.
>>>> * There are situations when there is an agreement between the service
>>>> provider and the connectivity provider about min and max bit-rates.
>>>> What: Again, this depends on how much BW info is included in the SDP.
>>>> But my understanding is that there should be some (since RTCP rates to
>>>> be used are based on this info IIUC).
>>> I agree and think we need to a couple things here. One is setting the
>>> limits for the bandwidth but the  other is using the stats interface to read
>>> the current bandwidth being used.
>>     A slightly related but higher-level proposal: replace Mandatory
>> constraints with Optional constraints that act as Fence conditions.
>>     It works like this: You specify a bunch of optional constraints and a
>> callback to be invoked when a Constraint is violated. For example, I would
>> ask for a bandwidth between 1Mbit and 2Mbit. If bandwidth drops below the
>> minimum, the callback gets invoked. I then reduce the video resolution, or
>> turn off audio, or... whatever the application wants... and set new min/max
>> bandwidth bounds. If the maximum bound is surpassed, I know I can afford to
>> increase the video resolution so I do so. And so on.
>>     Assuming I'm wrong (you need mandatory constraints) I still think
>> adding this fence behavior puts control in the right place. The application
>> is uniquely positioned to decide what happens when the connection
>> capabilities change.
>> Gili

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
– Linus Tordvals, creador del sistema operativo Linux
Received on Wednesday, 24 July 2013 13:18:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:50 UTC