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

Re: setting bandwidth

From: Kiran Kumar <g.kiranreddy4u@gmail.com>
Date: Wed, 24 Jul 2013 18:32:14 +0530
Message-ID: <CAGW1TF60gP_ATrn2yYVw5sHpm2+tE_DijipiWbRJWrRdhdohww@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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.


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 <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
Received on Wednesday, 24 July 2013 13:03:02 UTC

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