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

Re: setting bandwidth

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sun, 28 Jul 2013 23:18:58 +0200
Message-ID: <51F58AC2.9060604@alvestrand.no>
To: public-webrtc@w3.org
Just to reply to one concern raised:

The demo at
http://webrtc.googlecode.com/svn/trunk/samples/js/demos/html/constraints-and-stats.html
shows how one can display bandwidth usage based on reading stats counters.

The necessary code is present in Chrome 28 (stable).

(digging into this code will also allow people to get some idea of why
talking about "the bandwidth" is not such a simple idea as it first
appears to be).

             Harald

On 07/24/2013 06: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. 
>
>
>
Received on Sunday, 28 July 2013 21:19:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC