New class ReceiveSideCongestionController, extracted from CongestionController, and responsible for the
OnReceivedPacket processing.
Rest of the CongestionController moved to a new class
SendSideCongestionController.
To avoid breaking applications, CongestionController is redefined
as a union of these two classes, with no intended change in behavior.
With one exception: CongestionController::SetBweBitrates used to call
remote_bitrate_estimator_.SetMinBitrate, but after remote_bitrate_estimator_ was moved to ReceiveSideCongestionController,
it no longer does this.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2752233002
Cr-Commit-Position: refs/heads/master@{#17321}
1. GetTransportFeedbackVector will now return a vector which also explicitly states lost packets.
2. The returned vector is unsorted (uses default order - by sequence number). It's up to the users to sort otherwise, if they need a different order.
BUG=None
Review-Url: https://codereview.webrtc.org/2707383006
Cr-Commit-Position: refs/heads/master@{#17114}
It's the faster, less strict cousin of checked_cast.
BUG=none
Review-Url: https://codereview.webrtc.org/2714063002
Cr-Commit-Position: refs/heads/master@{#16958}
In order to not make this CL too large I have broken it down into at least two
steps. Previous CL: https://codereview.chromium.org/2628563003/
webrtc::PacedSender::Process <--- previous CL start here
webrtc::PacedSender::SendPacket
webrtc::PacketRouter::TimeToSendPacket
webrtc::ModuleRtpRtcpImpl::TimeToSendPacket <--- previous CL end here, this Cl start here
webrtc::RTPSender::TimeToSendPacket
webrtc::RTPSender::PrepareAndSendPacket
webrtc::RTPSender::AddPacketToTransportFeedback
webrtc::TransportFeedbackAdapter::AddPacket
webrtc::SendTimeHistory::AddAndRemoveOld <--- this CL end here
BUG=webrtc:6822
Review-Url: https://codereview.webrtc.org/2708873003
Cr-Commit-Position: refs/heads/master@{#16796}
Rename loss based and delay based bwe updates in proto (and correspondingly in the C++ code).
BUG=webrtc:6423
Review-Url: https://codereview.webrtc.org/2705613002
Cr-Commit-Position: refs/heads/master@{#16719}
In order to not make this CL too large I have broken it down into at least two steps. In this CL we only propagate the pacing information part of the way:
webrtc::PacedSender::Process <--- propagate from here
webrtc::PacedSender::SendPacket
webrtc::PacketRouter::TimeToSendPacket
webrtc::ModuleRtpRtcpImpl::TimeToSendPacket <--- to here
webrtc::RTPSender::TimeToSendPacket
webrtc::RTPSender::PrepareAndSendPacket
webrtc::RTPSender::AddPacketToTransportFeedback
webrtc::TransportFeedbackAdapter::AddPacket
webrtc::SendTimeHistory::AddAndRemoveOld <--- goal is to propagte it here
BUG=webrtc:6822
Review-Url: https://codereview.webrtc.org/2628563003
Cr-Commit-Position: refs/heads/master@{#16664}
Lateness is determined by the length of the send-side history, currently
set to 60 seconds.
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/2684353004
Cr-Commit-Position: refs/heads/master@{#16588}
This helps us avoid time-outs on really bad networks with long queues.
Also adding periodic logging of the fake network pipe's queue in milliseconds.
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/2687013005
Cr-Commit-Position: refs/heads/master@{#16532}
This avoids issues where the bitrate produced by the codec is far lower than the target bitrate in the beginning, which causes the delay-based BWE to be initialized accordingly.
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/2653883002
Cr-Commit-Position: refs/heads/master@{#16327}
This means that smaller probe packets will be allowed at lower bitrates.
BUG=webrtc:7043
Review-Url: https://codereview.webrtc.org/2650393002
Cr-Commit-Position: refs/heads/master@{#16317}
It was only assigned at construction, and this improves consistency
with remote_estimator_proxy_.
The declaration of the private WrappingBitrateEstimator had to be
moved to the header file, and it was also converted from
system_wrappers' CriticalSectionWrapper to rtc::CriticalSection.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2642363003
Cr-Commit-Position: refs/heads/master@{#16236}
It combines and simplify use of GetStatusVector and GetReceiveDeltas accesors.
Replace use of all GetStatusVector/GetReceiveDeltasUs
BUG=None
Review-Url: https://codereview.webrtc.org/2633923003
Cr-Commit-Position: refs/heads/master@{#16139}
Also rename it from pacer_thread_ to congestion_controller_thread_.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2637783003
Cr-Commit-Position: refs/heads/master@{#16134}
This lets the RTP code be unaware of lower layers, and the
SetTransportOverhead method is deleted from RTPSender and RtpRtcp.
Instead, that method is added to CongestionController and
TransportFeedbackAdapter, where it is more appropriate.
BUG=wertc:6847
Review-Url: https://codereview.webrtc.org/2589743002
Cr-Commit-Position: refs/heads/master@{#15995}
Instead of having to specify a bitrate and how many packets to use,
the BitrateProber will now use the bitrate to calculate how many
bytes it will use to probe that bitrate instead.
For now, |kMinProbeDurationMs| is set to 15 ms which means that probing
at 1900 kbps will result in 1900/8*0.015 = 3.5 kB used. Since we can
expect packets to be smaller at the beginning of a stream (500 to 700
bytes) this will result in 7 to 5 packets sent for that bitrate, and
should work very similar to how the current initial probing works.
A minimum of 5 packets are always sent.
BUG=webrtc:6822
Review-Url: https://codereview.webrtc.org/2609113003
Cr-Commit-Position: refs/heads/master@{#15899}
Problem fixed: RTP header extensions were not properly set in tests.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2593963003
Cr-Commit-Position: refs/heads/master@{#15741}
This also avoids an issue where -1 is interpreted as 0xFFFF by the feedback adapter, which in practice likely isn't a problem, but still wrong.
BUG=None
Review-Url: https://codereview.webrtc.org/2579263002
Cr-Commit-Position: refs/heads/master@{#15647}
Previously ProbeController would overflow int when calculating
min_bitrate_to_probe_further_bps and when probing bitrate is
above 17 Mbps. The problem was introduced in
https://codereview.webrtc.org/2504023002. Fixed ProbeController to use
int64_t internally for bitrate calculations.
BUG=6332
Review-Url: https://codereview.webrtc.org/2574533002
Cr-Commit-Position: refs/heads/master@{#15642}
