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
8 files changed
