44caf01c34
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@5794 4adac7df-926f-26a2-2b94-8c16560cd09d