Re: setting bandwidth

It's not bad to have the timers inside the API, but I would wait until
more clear use cases apear.

2013/7/24 Kiran Kumar <g.kiranreddy4u@gmail.com>:
> Dear Goran Eriksson/Piranna,
>
> Yes, It can be done by application too.
> But maintaining such timer in the lower level, might be more appropriate. It
> will reduce unnecessary call backs.
> (Even though this is may not be the perfect example, some signaling
> protocols like SIP are maintaining their timers in the lower layers instead
> of application layer).
>
> Thanks,
> Kiran.
>
>
>
> On Wed, Jul 24, 2013 at 6:47 PM, Göran Eriksson AP
> <goran.ap.eriksson@ericsson.com> wrote:
>>
>>
>>
>> 24 jul 2013 kl. 15:04 skrev "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.
>>
>>
>> That is an option but is that not up to the application to have a timer, a
>> counter or what ever is needed to decide on an action?
>>
>>
>>
>>
>>
>>
>> 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
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Received on Wednesday, 24 July 2013 13:36:07 UTC