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}
Currently we limit the enocder so that frames aren't encoded if the
expected pacer queue is longer than 2s. However, if the queue is full
and the bitrate suddenly drops (or there is a large overshoot), the
queue time can be long than the limit.
This CL allows the pacer to temporarily boost the pacing bitrate over
the 2s window.
BUG=
Review URL: https://codereview.webrtc.org/1412293003
Cr-Commit-Position: refs/heads/master@{#10729}
This changes the following module directories:
* webrtc/modules/audio_conference_mixer/interface
* webrtc/modules/interface
* webrtc/modules/media_file/interface
* webrtc/modules/rtp_rtcp/interface
* webrtc/modules/utility/interface
To avoid breaking downstream, I followed this recipe:
1. Copy the interface dir to a new sibling directory: include
2. Update the header guards in the include directory to match the style guide.
3. Update the header guards in the interface directory to match the ones in include. This is required to avoid getting redefinitions in the not-yet-updated downstream code.
4. Add a pragma warning in the header files in the interface dir. Example:
#pragma message("WARNING: webrtc/modules/interface is DEPRECATED; "
"use webrtc/modules/include")
5. Search for all source references to webrtc/modules/interface and update them to webrtc/modules/include (*.c*,*.h,*.mm,*.S)
6. Update all GYP+GN files. This required manual inspection since many subdirectories of webrtc/modules referenced the interface dir using ../interface etc(*.gyp*,*.gn*)
BUG=5095
TESTED=Passing compile-trybots with --clobber flag:
git cl try --clobber --bot=win_compile_rel --bot=linux_compile_rel --bot=android_compile_rel --bot=mac_compile_rel --bot=ios_rel -m tryserver.webrtc
R=stefan@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1417683006 .
Cr-Commit-Position: refs/heads/master@{#10500}
Since the pacer is always enabled, removing enable/disable which makes
all packet queueing succeed. Also renaming one of the ::SendPackets
::InsertPacket to avoid confusion.
BUG=webrtc:1695, webrtc:2629
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1392513002 .
Cr-Commit-Position: refs/heads/master@{#10211}
To make this possible padding only packets will have the same timestamp
as the previously sent media packet, as long as RTX is not enabled. This
has the side effect that if we send only padding for a long time without
sending media, a receive-side jitter buffer could potentially overflow.
In practice this shouldn't be an issue, partly because RTX is recommended and
used by default, but also because padding typically is terminated before being
received by a client. It is also not an issue for bandwidth estimation as long
as abs-send-time is used instead of toffset.
BUG=chromium:425925
R=mflodman@webrtc.org, sprang@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1327933003 .
Cr-Commit-Position: refs/heads/master@{#9984}
This improves self-fairness and competing for resources with TCP flows.
BUG=4711
Review URL: https://codereview.webrtc.org/1151603008
Cr-Commit-Position: refs/heads/master@{#9545}
This fixes a variety of MSVC warnings about value truncations when implicitly
storing the 64-bit values we get back from e.g. TimeTicks in 32-bit objects, and
removes the need for a number of explicit casts.
This also moves a number of constants so they're declared right where they're used, which is easier to read and maintain, and makes some of them of integral type rather than using the "enum hack".
BUG=chromium:81439
TEST=none
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33649004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7905 4adac7df-926f-26a2-2b94-8c16560cd09d
Packet queue in the paced sender is now based on a priority queue rather than having a separate fifo-queue per priority level. This allows more flexible sorting and cleaner usage.
Packets with earlier capture times are now prioritized higher. In situations with high packet loss, the queue might contain packets from several subsequent frames. Retransmit packets from the earlier frames first, since the later ones will probably be dependent on these.
Also, don't force sending of packets after a certain time of inactivity or when packets grow too old, since this was causing consistent overuse on poor connections. Instead, drop frames in vie encoder if pacer queue is too long.
BUG=
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/27869004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7617 4adac7df-926f-26a2-2b94-8c16560cd09d
With this CL the resolution is increased to microseconds and proper rounding
is done in the Process() function. This means that we will be allowed to send
more than prior to r6664 as we previously truncated away parts of our budget.
We will also not lose budget due to inaccurate calculations in
TimeUntilNextProcess(), which was a regression in r6664.
BUG=cr/393950
TEST=out/Debug/webrtc_perf_tests --gtest_filter=RampUpTest.Simulcast
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20949004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6694 4adac7df-926f-26a2-2b94-8c16560cd09d
