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

[Bug 15861] API for JS interaction with congestion control

From: <bugzilla@jessica.w3.org>
Date: Wed, 04 Sep 2013 03:46:46 +0000
To: public-webrtc@w3.org
Message-ID: <bug-15861-4991-b06o6oIitv@http.www.w3.org/Bugs/Public/>
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

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