tree 2532a2caeda929bc4eb2b610faa434cafa6d6729
parent ba755922422516cd93132089d0828198b886db7f
author andresp@webrtc.org <andresp@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> 1395867621 +0000
committer andresp@webrtc.org <andresp@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> 1395867621 +0000

Re-submit: rev5775

Modify bitrate controller to update bitrate based on process call and not
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

git-svn-id: http://webrtc.googlecode.com/svn/trunk/webrtc@5794 4adac7df-926f-26a2-2b94-8c16560cd09d