only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5775 4adac7df-926f-26a2-2b94-8c16560cd09d
Camera start is a blocking operation so never a good idea to do on a main
thread, but worse than that is that the guts of WebView appear to be
interacting with capture start in a bad way causing startup to pause for 10s
while a timeout expires. This change eliminates that 10s delay.
R=noahric@google.com
Review URL: https://webrtc-codereview.appspot.com/10449004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5772 4adac7df-926f-26a2-2b94-8c16560cd09d
These changes are currently not used in webrtc/ but helps in using the delay estimator.
* The last_delay_quality() is updated with respect to robust_validation and changed to return float.
* Tests are updated wtih respect to above.
* Adds the possibility to make a soft reset based on external circumstances like a known delay shift has been made.
* The soft reset change the lookahead dynamically. An API to ask for current lookahead has been added as well.
BUG=N/A
TESTED=trybots, modules_unittest
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10409004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5761 4adac7df-926f-26a2-2b94-8c16560cd09d
To be used by a codec implementation. Could for instance be interpreted
as trying to fit as much as possible on one temporal layer and send
everything that doesn't fit within target bitrate on another one.
Prevents an existing hack where startBitrate is used by a codec
implementation to signify target bitrate. This hack forces a reset of
bitrate estimation to target bitrate which creates bitrate dips.
BUG=
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10479004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5759 4adac7df-926f-26a2-2b94-8c16560cd09d
- Move condition of 0 bps as max meaning 1gbps from SendSideBandwidthEstimation to BitrateController.
- Remove condition on bitrate=0 meaning bandwidth estimation off as that could only happen when no observers existed
and in which case the estimation would be ignored.
- Add MaybeTriggerOnNetworkChanged which only runs rate allocation if any of the dependent variables has changed
thus allowing to remove many of the bool returns that try to indicate if the estimation has changed which would not
be aware if the observers have changed.
- SendSideBandwidthEstimation now has a UpdateBitrate and has clear code paths to which calls update bitrate.
- Changes in enforce_min_bitrate so the 10kbps min is set from the BitrateController and not from the outside this keep valid as observers are changed.
R=henrik.lundin@webrtc.org, stefan@webrtc.org
BUG=3065
Review URL: https://webrtc-codereview.appspot.com/10189004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5752 4adac7df-926f-26a2-2b94-8c16560cd09d
In the case where a network glitch causes a packet to arrive so late
that the jitter buffer has gone into expand mode, the playout timestamp
could have been increased to a value that is larger than the RTP
timestamp of the late packet when it finally arrives. This causes
the difference to be negative, and would make the value wrap (unsigned).
With this fix, the difference is set to zero when the playout
timestamp is ahead of the incoming RTP timestamp. Further down in the
method, a zero-value will lead to the averaging filter not being updated.
BUG=3080
R=henrika@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10199004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5735 4adac7df-926f-26a2-2b94-8c16560cd09d
GetWindowRect includes the window frames for maximized window even they are off screen, causing content outside the window being captured falsely. The fix is to remove the left/right/bottom window frame from the captured rect. Mouse capturing is adjusted accordingly as well.
BUG=3076
R=sergeyu@chromium.org
Review URL: https://webrtc-codereview.appspot.com/10149004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5732 4adac7df-926f-26a2-2b94-8c16560cd09d
- An RTX packet with no payload should be dropped prior to parsing RTX header since it doesn't have an RTX header. This can for example happen when sending padding-only packets over the RTX stream.
- The retransmit code path when the pacer is disabled doesn't properly update the abs-send-time and ts-offset header extensions.
TEST=trybots
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9189004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5728 4adac7df-926f-26a2-2b94-8c16560cd09d
