- From: <piranna@gmail.com>
- Date: Wed, 24 Jul 2013 15:17:22 +0200
- 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 Unix." – Linus Tordvals, creador del sistema operativo Linux
Received on Wednesday, 24 July 2013 13:18:10 UTC