webrtc_m130/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.h

61 lines
2.0 KiB
C
Raw Normal View History

/*
* Copyright (c) 2012 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*
* FEC and NACK added bitrate is handled outside class
*/
#ifndef WEBRTC_MODULES_BITRATE_CONTROLLER_SEND_SIDE_BANDWIDTH_ESTIMATION_H_
#define WEBRTC_MODULES_BITRATE_CONTROLLER_SEND_SIDE_BANDWIDTH_ESTIMATION_H_
#include "webrtc/modules/rtp_rtcp/interface/rtp_rtcp_defines.h"
#include "webrtc/system_wrappers/interface/critical_section_wrapper.h"
namespace webrtc {
class SendSideBandwidthEstimation {
public:
SendSideBandwidthEstimation();
virtual ~SendSideBandwidthEstimation();
void CurrentEstimate(uint32_t* bitrate, uint8_t* loss, uint32_t* rtt) const;
// Call when we receive a RTCP message with TMMBR or REMB.
void UpdateReceiverEstimate(uint32_t bandwidth);
// Call when we receive a RTCP message with a ReceiveBlock.
void UpdateReceiverBlock(uint8_t fraction_loss,
uint32_t rtt,
int number_of_packets,
uint32_t now_ms);
void SetSendBitrate(uint32_t bitrate);
void SetMinMaxBitrate(uint32_t min_bitrate, uint32_t max_bitrate);
void SetMinBitrate(uint32_t min_bitrate);
private:
Revert 5775 "Modify bitrate controller to update bitrate based o..." This triggered an occasional TSAN failure in CallTest.ReceivesPliAndRecoversWithNack e.g.: http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1444/steps/memory%20test%3A%20video_engine_tests/logs/stdio I managed to reproduce this locally and verified that reverting this CL corrected it. > 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 > > Review URL: https://webrtc-codereview.appspot.com/10529004 TBR=andresp@webrtc.org Review URL: https://webrtc-codereview.appspot.com/10079005 git-svn-id: http://webrtc.googlecode.com/svn/trunk@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
2014-03-25 19:42:39 +00:00
void UpdateEstimate(uint32_t now_ms);
void CapBitrateToThresholds();
// incoming filters
int accumulate_lost_packets_Q8_;
int accumulate_expected_packets_;
uint32_t bitrate_;
uint32_t min_bitrate_configured_;
uint32_t max_bitrate_configured_;
uint8_t last_fraction_loss_;
Revert 5775 "Modify bitrate controller to update bitrate based o..." This triggered an occasional TSAN failure in CallTest.ReceivesPliAndRecoversWithNack e.g.: http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1444/steps/memory%20test%3A%20video_engine_tests/logs/stdio I managed to reproduce this locally and verified that reverting this CL corrected it. > 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 > > Review URL: https://webrtc-codereview.appspot.com/10529004 TBR=andresp@webrtc.org Review URL: https://webrtc-codereview.appspot.com/10079005 git-svn-id: http://webrtc.googlecode.com/svn/trunk@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
2014-03-25 19:42:39 +00:00
uint16_t last_round_trip_time_;
uint32_t bwe_incoming_;
Revert 5775 "Modify bitrate controller to update bitrate based o..." This triggered an occasional TSAN failure in CallTest.ReceivesPliAndRecoversWithNack e.g.: http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1444/steps/memory%20test%3A%20video_engine_tests/logs/stdio I managed to reproduce this locally and verified that reverting this CL corrected it. > 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 > > Review URL: https://webrtc-codereview.appspot.com/10529004 TBR=andresp@webrtc.org Review URL: https://webrtc-codereview.appspot.com/10079005 git-svn-id: http://webrtc.googlecode.com/svn/trunk@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
2014-03-25 19:42:39 +00:00
uint32_t time_last_increase_;
uint32_t time_last_decrease_;
};
} // namespace webrtc
#endif // WEBRTC_MODULES_BITRATE_CONTROLLER_SEND_SIDE_BANDWIDTH_ESTIMATION_H_