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}
Reason for revert:
Multiple definitions of TestEstimator
Original issue's description:
> Avoid precision loss in TrendlineEstimator by passing the arrival time as an int64_t instead of a double.
>
> BUG=webrtc:6884
>
> Committed: https://crrev.com/c12cbaf9dd0729dd45f3fc45a1938d1b3455e40a
> Cr-Commit-Position: refs/heads/master@{#15631}
TBR=stefan@webrtc.org,brandtr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6884
Review-Url: https://codereview.webrtc.org/2582513002
Cr-Commit-Position: refs/heads/master@{#15636}
Reason for revert:
Multiple definitions of TestEstimator
Original issue's description:
> Pass arrival time as an int64_t rather than a double to the MedianSlopeEstimator to avoid precision loss.
>
> Also clean up the unit test.
>
> BUG=webrtc:6892
>
> Committed: https://crrev.com/ebcbcc3b2451f5c4fb07f7b37815bd54f364d057
> Cr-Commit-Position: refs/heads/master@{#15634}
TBR=brandtr@webrtc.org,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6892
Review-Url: https://codereview.webrtc.org/2572353003
Cr-Commit-Position: refs/heads/master@{#15635}
Theil and Sen's estimator essentially looks at the line through every pair of points and selects the median slope. This is robust to corruption of up to 29% of the data points.
Wire up new estimator to field trial experiment. Add unit and integration tests. Results are promising.
BUG=webrtc:6728
Review-Url: https://codereview.webrtc.org/2512693002
Cr-Commit-Position: refs/heads/master@{#15508}
Also deletes one call to CongestionController::pacer.
BUG=None
Review-Url: https://codereview.webrtc.org/2542113003
Cr-Commit-Position: refs/heads/master@{#15479}
https://codereview.webrtc.org/2504023002 broke exponential probing.
After that change ProbeController stops exponential probes prematurely:
it goes to kProbingComplete state if SetEstimatedBitrate() is called
with bitrate lower than min_bitrate_to_probe_further_bps_, which always
happens with the first pair of probes. As result it wasn't sending
repeated probes as it should. This change fixes that issue by moving
probe expieration logic to ProbeContoller::Process(). This also ensures
that the controller goes to kProbingComplete state as soon as probing
timeout expired, without waiting for the next SetEstimatedBitrate()
call.
BUG=669421
Review-Url: https://codereview.webrtc.org/2546613003
Cr-Commit-Position: refs/heads/master@{#15392}
And delete the method CongestionController::packet_router.
BUG=None
Review-Url: https://codereview.webrtc.org/2516983004
Cr-Commit-Position: refs/heads/master@{#15323}
