- From: <bugzilla@jessica.w3.org>
- Date: Wed, 04 Sep 2013 03:46:46 +0000
- To: public-webrtc@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15861 Gili <cowwoc@bbs.darktech.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cowwoc@bbs.darktech.org --- Comment #6 from Gili <cowwoc@bbs.darktech.org> --- I'd like to propose the following: 1. The user is allowed to specify "fence conditions" and a callback. An example of fence conditions are minimum or maximum bandwidth. 2. If WebRTC is forced to "cross" one of these boundaries, it fires the callback. 3. The callback should respond by altering the video properties and/or fence conditions and the process repeats ad infinitum. For example, I set a minimum bandwidth of 50kbps, and maximum bandwidth of 1000kbps. If the minimum bandwidth is crossed, I decide to either increase the video resolution or (if the video is as big as I'd like) reduce the minimum bandwidth fence. If the maximum bandwidth is crossed, I respond by reducing the video resolution or (if the video is as small as I'd like) increase the maximum bandwidth fence. How should bitrate, frame rate and resolution constraints interact with one another? Which should get priority over the other? This approach puts the application in control, because ultimately the application is the only one that knows the answer to that question. Obviously you can layer timers on top of this. Meaning, application can decide to react only if the maximum bandwidth fence is crossed for over 3 seconds (and ignore it otherwise). This approach is not specific to congestion control. It can be applied to all other constraints as well. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
Received on Wednesday, 4 September 2013 03:46:47 UTC