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}
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}
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}
There's no longer any need to make the two arguments have the same
signedness, so we can drop the "u" suffix on literal integer
arguments.
NOPRESUBMIT=true
BUG=webrtc:6645
Review-Url: https://codereview.webrtc.org/2535593002
Cr-Commit-Position: refs/heads/master@{#15280}
Now ProbeController can send periodic bandwidth probes when in
application-limited region. This will allow to maintain correct
bottleneck bandwidth estimate, even not all bandwidth is being used.
The feature is not enabled by default, but can be enabled with a flag.
Interval between probes is currently set to 5 seconds.
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2504023002
Cr-Commit-Position: refs/heads/master@{#15279}
Previously AlrDetector was measuring amount of data sent in each 100ms
interval and would enter ALR mode after 5 consecutive intervals when
average bandwidth usage doesn't exceed 30% of the current estimate
estimate. This meant that an application that uses only slightely more
than 6% of total bandwidth may stay out of ALR mode, e.g. if it sends
a frame of size BW*30ms every 0.5 seconds. 100ms is too short interval
to average over, particularly when frame-rate falls below 10fps.
With this change AlrDetector averages BW usage over last 500ms. It then
enters ALR state when usage falls below 30% and exits it when usage
exceeds 50%.
BUG=webrtc:6332
R=philipel@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2503643003 .
Cr-Commit-Position: refs/heads/master@{#15109}
This is a simple application limited region detector that is quite conservative
at the moment. We detect as being application-limited if we see sending rate
as less than 30% of the estimated bandwidth over 500 ms. The moment we detect
a single burst above 30% over a 100 ms period, we consider ourselves network
limited.
This class is currently not used. A follow up CL will leverage this to enable probing.
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2340763004
Cr-Commit-Position: refs/heads/master@{#14505}
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}
The intended behavior of the pacer is that it should send audio (i.e high priority) packets immediatelly even if the pacer is paused and even if the available media budget has been used. The existing code will not send audio if the pacing budget has been used. It will normally send audio when the pacer is paused, but if the media budget was already used up when the pacer was paused, it would neither send audio nor update the budget.
Updated the implementatation and the unit test. Added logging for when the pacer is paused, and when it receives a zero bitrate estimate.
BUG=webrtc:6155
Review-Url: https://codereview.webrtc.org/2193183003
Cr-Commit-Position: refs/heads/master@{#13592}
Retransmissions are supposed to be sent before normal packets by the pacer, but the current implementation will only use it if the second packet is a retransmission and the first packet is not. It misses the case where the first packet is retransmission and the second packet is not.
This CL fixes the comparator and adds a unit test.
Also changed the SendAndExpectPacket function to propagate the retransmission flag to the expectations. Previously, all packets were expected to be normal packets.
BUG=webrtc:6124
Review-Url: https://codereview.webrtc.org/2156063004
Cr-Commit-Position: refs/heads/master@{#13502}
1. It moves calculation of the needed padding to VideoSendStream instead of ViEEncoder and only does it once per send Stream instead of every time the network estimate changes.
2. The maximum amount of padding sent was prior to this cl calculated and updated based on network estimate changes. However, it can only change based on encoder configuration changes and if send streams are added or removed. This cl change the VideoSendStream/VieEncoder to notify the BitrateAllocator of changes to the needed padding bitrate and for BitrateAllocator to notify Call of these changes.
3. Fixed an issue in the SendPacer where it could send a padding packet before sending a real packet. This caused the test EndToEndTest.RestartingSendStreamPreservesRtpStatesWithRtx to fail with these refactorings since the pacer suddenly could send a padding packet before the encoder had produced its first frame.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/1993113003
Cr-Commit-Position: refs/heads/master@{#13149}
This reverts commit e30c27205148b34ba421184efe65f6a0780b436d (https://codereview.webrtc.org/1958053002/)
Original reverted cl is in patch set #1.
Changes in following patch sets.
The cl now also make sure SendPacer starts with the configured bitrate provided in a call to CongestionController::SetBweBitrates)()
It turns out that the failing tests in 609816 is due to a bug in the current code that runs the proper at 300kbit regardless of configured start bitrate.
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)
BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
NOTRY=True // Due to bug in android_x86 cq builder....
Review-Url: https://codereview.webrtc.org/1958113003
Cr-Commit-Position: refs/heads/master@{#12688}
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}
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)
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/1917793002
Cr-Commit-Position: refs/heads/master@{#12620}
Reason for revert:
Revert breaks other uses, a fix will be rolled into Chromium instead.
Original issue's description:
> Revert of Remove ignored return code from modules. (patchset #3 id:40001 of https://codereview.webrtc.org/1703833002/ )
>
> Reason for revert:
> Breaks Chromium.
>
> Original issue's description:
> > Remove ignored return code from modules.
> >
> > ModuleProcessImpl doesn't act on return codes and having them around is
> > confusing (it's unclear what an error return code here would do even).
> >
> > BUG=
> > R=tommi@webrtc.org
> >
> > Committed: f14c47a58c
>
> TBR=tommi@webrtc.org,pbos@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=
>
> Committed: https://crrev.com/da33a8a2a22f6d19ba2a8cce963beafbdbaa8fd8
> Cr-Commit-Position: refs/heads/master@{#11761}
TBR=tommi@webrtc.org,torbjorng@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.webrtc.org/1737013002
Cr-Commit-Position: refs/heads/master@{#11762}
Reason for revert:
Breaks Chromium.
Original issue's description:
> Remove ignored return code from modules.
>
> ModuleProcessImpl doesn't act on return codes and having them around is
> confusing (it's unclear what an error return code here would do even).
>
> BUG=
> R=tommi@webrtc.org
>
> Committed: f14c47a58cTBR=tommi@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.webrtc.org/1736663004
Cr-Commit-Position: refs/heads/master@{#11761}
ModuleProcessImpl doesn't act on return codes and having them around is
confusing (it's unclear what an error return code here would do even).
BUG=
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1703833002 .
Cr-Commit-Position: refs/heads/master@{#11747}
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}
Once we have eliminated all non-monotonic clocks, revert this change.
BUG=webrtc:5452
Review URL: https://codereview.webrtc.org/1618333002
Cr-Commit-Position: refs/heads/master@{#11361}
We should only account for audio packets in the pacer budget if we also
are allocating bandwidth for the audio streams.
BUG=chromium:567659,webrtc:5263
R=mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1524763002 .
Cr-Commit-Position: refs/heads/master@{#11053}
This CL contains three changes as a preparation for adding audio send streams
to the send-side BWE:
1. Audio packets are passed through the pacer with high priority. This
is needed to be able to set transport sequence numbers on the packets.
2. A feedback observer is passed to the audio stream's rtcp receiver so
that the BWE can get notified of any BWE feedback being received on the
audio feedback channel.
3. Support for the transport sequence number header extension is added
to audio send streams.
BUG=webrtc:5263,webrtc:5307
R=mflodman@webrtc.org, solenberg@webrtc.org
Review URL: https://codereview.webrtc.org/1479023002 .
Cr-Commit-Position: refs/heads/master@{#10909}
