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}
Previously BirateProber was calculating delay between probes based on
the size of the previous probe. Because of that the actual sent bitrate
can deviate greatly from the target value. With this change it uses
total number of bytes in the cluster to estimate delay before each
probe.
BUG=webrtc:6952
Review-Url: https://codereview.webrtc.org/2613543003
Cr-Original-Commit-Position: refs/heads/master@{#15971}
Committed: 599c5011e7
Review-Url: https://codereview.webrtc.org/2613543003
Cr-Commit-Position: refs/heads/master@{#16127}
Reason for revert:
Speculative revert.
Linux memcheck bot started failing a lot at the time of this cl. Doesn't look related at first glance, but we don't have another lead yet.
Original issue's description:
> Fix BitrateProber to match the requested bitrate more precisely
>
> Previously BirateProber was calculating delay between probes based on
> the size of the previous probe. Because of that the actual sent bitrate
> can deviate greatly from the target value. With this change it uses
> total number of bytes in the cluster to estimate delay before each
> probe.
>
> BUG=webrtc:6952
>
> Review-Url: https://codereview.webrtc.org/2613543003
> Cr-Commit-Position: refs/heads/master@{#15971}
> Committed: 599c5011e7TBR=philipel@webrtc.org,stefan@webrtc.org,sergeyu@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6952
Review-Url: https://codereview.webrtc.org/2626473004
Cr-Commit-Position: refs/heads/master@{#15979}
Previously BirateProber was calculating delay between probes based on
the size of the previous probe. Because of that the actual sent bitrate
can deviate greatly from the target value. With this change it uses
total number of bytes in the cluster to estimate delay before each
probe.
BUG=webrtc:6952
Review-Url: https://codereview.webrtc.org/2613543003
Cr-Commit-Position: refs/heads/master@{#15971}
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}
Currently, BitrateProber does not scale higher than 2 Mbps to 6 Mbps. The actual
number is dependent on the size of the last packet. If a packet of around 250
bytes is used for probing, it fails above 2 Mbps.
BitrateProber now provides a recommendation on probe size instead of a
packet size. PacedSender utilizes this to decide on the number of packets
per probe. This enables BitrateProber to scale up-to higher bitrates.
Tests with chromoting show it stalls at about 10 Mbps (perhaps due to the
limitation on the simulation pipeline to deliver packets).
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2347023002
Cr-Commit-Position: refs/heads/master@{#14503}
- Removes unnecessary casts to compute timedelta.
- Renames ProbingState for clarity. This should help when we probe mid-call.
- Enables probing by default to avoid checking on each incoming packet.
- Removes duplicate probing state tracking in paced sender. These duplicate
states were conflicting at times.
- Removes passing through packets for bug 5307 which seems long fixed.
- Cleanup handling of time_last_send_ms and avoid side effects of changing
probing state at TimeUntilNextProbe().
- Clear cluster data when probing is restarted to avoid having old data after a reset.
BUG=5859
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2182603002 .
Cr-Commit-Position: refs/heads/master@{#13612}
This reverts commit 825eb58d59940a4c3c9837595c4b3b07059c93ca.
This Relands the cl reviewed in https://codereview.webrtc.org/1917793002/
patchset #1 is a pure reland.
patchset #2 fix an overflow in BitrateProber that caused WebRtcVideoChannel2BaseTest.TwoStreamsSendAndReceive to fail.
Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the BitrateController. If the queue is full, the controller reports a bitrate of zero to Call (and BitrateAllocator)
R=stefan@webrtc.orgTBR=mflodman@webrtc.org
BUG=webrtc:5687
Review URL: https://codereview.webrtc.org/1947873002 .
Cr-Commit-Position: refs/heads/master@{#12630}
Skip accounting for small packets and suspend the prober if no
large-enough packets have been sent for some time. This especially seems
to have triggered in audio-only calls where all packets are too small,
making TimeUntilNextProbe return 0 forever, causing the module process
thread to wake up forever.
BUG=webrtc:5506
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1688703002 .
Cr-Commit-Position: refs/heads/master@{#11634}
These small packets are common for H.264 where the first packet of an IDR
contains the parameter sets.
BUG=4806
Review URL: https://codereview.webrtc.org/1221943002
Cr-Commit-Position: refs/heads/master@{#9639}
