From 1c392cc5cf83630eaaa0401954b66149c1760ebc Mon Sep 17 00:00:00 2001 From: skvlad Date: Fri, 1 Apr 2016 14:46:44 -0700 Subject: [PATCH] Avoid rescheduling the next RTCP packet if the RTCP sender status doesn't change. The change made in https://codereview.webrtc.org/1757683002 introduced an extra call to RTCPSender::SetRTCPStatus after the video receive stream is created. The SetRTCPStatus call results in no state change, as the RTCP sender is already enabled, however, it reschedules the next RTCP packet to be RTCP_INTERVAL_VIDEO_MS/2 (500) ms in the future. Before the change, the next packet time was only set by the previous call to RTCPSender::SetSSRC, which placed it 100 ms in the future. The change, therefore, changed the timing of multiple performance tests - as it now takes a different length of time to ramp up to the same bandwidth. BUG=chromium:597332 Review URL: https://codereview.webrtc.org/1826093004 Cr-Commit-Position: refs/heads/master@{#12203} --- webrtc/modules/rtp_rtcp/source/rtcp_sender.cc | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/webrtc/modules/rtp_rtcp/source/rtcp_sender.cc b/webrtc/modules/rtp_rtcp/source/rtcp_sender.cc index 440bd50d57..95bfeeea1f 100644 --- a/webrtc/modules/rtp_rtcp/source/rtcp_sender.cc +++ b/webrtc/modules/rtp_rtcp/source/rtcp_sender.cc @@ -208,15 +208,16 @@ RtcpMode RTCPSender::Status() const { return method_; } -void RTCPSender::SetRTCPStatus(RtcpMode method) { +void RTCPSender::SetRTCPStatus(RtcpMode new_method) { rtc::CritScope lock(&critical_section_rtcp_sender_); - method_ = method; - if (method == RtcpMode::kOff) - return; - next_time_to_send_rtcp_ = + if (method_ == RtcpMode::kOff && new_method != RtcpMode::kOff) { + // When switching on, reschedule the next packet + next_time_to_send_rtcp_ = clock_->TimeInMilliseconds() + (audio_ ? RTCP_INTERVAL_AUDIO_MS / 2 : RTCP_INTERVAL_VIDEO_MS / 2); + } + method_ = new_method; } bool RTCPSender::Sending() const {