In order to eliminate the WebRTC Subtree mirror in Chromium,
WebRTC is moving the content of the src/webrtc directory up
to the src/ directory.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=tommi@webrtc.org
Bug: chromium:611808
Change-Id: Iac59c5b51b950f174119565bac87955a7994bc38
Reviewed-on: https://webrtc-review.googlesource.com/1560
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19845}
1) Entering PROBE_RTT when necessary.
2) Congestion window gain of 0.65 instead of constant 4 packets.
3) {1.1, 0.9} pair instead of {1.25, 0.75}
4) Recovery mode.
5) No reaction to losses due to Recovery mode's implementation.
6) Supports encoder.
7) A new test compiling most of the simulation tests.
8) Bucket for high gain phase, disabled by default.
9) Pacer specific to BBR.
BUG=webrtc:7713
Review-Url: https://codereview.webrtc.org/2999073002
Cr-Commit-Position: refs/heads/master@{#19418}
This allows to protect ssrc_to_last_received_extended_high_seq_num_ member and
make calls to OnReceivedRtcpReceiverReport thread-safe without introducing new critical section.
Bug: webrtc:7735
Change-Id: Iee23bb780d07b0f906f1f8eeddde2b74cc0a2b89
Reviewed-on: https://chromium-review.googlesource.com/518130
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18540}
To achieve this some refactoring was done to make it possible to synchronize
access to the DelayBasedBwe in TransportFeedbackAdapter:
- The callback was removed from DelayBasedBwe, it now instead returns its
result.
- TransportFeedbackAdapter was moved to modules/congestion_controller to avoid
unnecessary dependencies.
Reenables previously disabled flaky test. Can no longer reproduce flakiness with gtest-parallel and asan/tsan builds.
BUG=webrtc:6427, webrtc:6422
R=terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2378103005 .
Cr-Commit-Position: refs/heads/master@{#14452}
Reason for revert:
Caused issues with webrtc_perf_tests on build bots.
Original issue's description:
> Fix race / crash in OnNetworkRouteChanged().
>
> To achieve this some refactoring was done to make it possible to synchronize
> access to the DelayBasedBwe in TransportFeedbackAdapter:
> - The callback was removed from DelayBasedBwe, it now instead returns its
> result.
> - TransportFeedbackAdapter was moved to modules/congestion_controller to avoid
> unnecessary dependencies.
>
> Reenables previously disabled flaky test. Can no longer reproduce flakiness with gtest-parallel and asan/tsan builds.
>
> BUG=webrtc:6427, webrtc:6422
>
> Committed: https://crrev.com/fd0d42669204e6dd92a60736bca7ae0196663024
> Cr-Commit-Position: refs/heads/master@{#14430}
TBR=terelius@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6427, webrtc:6422
Review-Url: https://codereview.webrtc.org/2377303002
Cr-Commit-Position: refs/heads/master@{#14433}
To achieve this some refactoring was done to make it possible to synchronize
access to the DelayBasedBwe in TransportFeedbackAdapter:
- The callback was removed from DelayBasedBwe, it now instead returns its
result.
- TransportFeedbackAdapter was moved to modules/congestion_controller to avoid
unnecessary dependencies.
Reenables previously disabled flaky test. Can no longer reproduce flakiness with gtest-parallel and asan/tsan builds.
BUG=webrtc:6427, webrtc:6422
Review-Url: https://codereview.webrtc.org/2366333003
Cr-Commit-Position: refs/heads/master@{#14430}
Reason for revert:
Reverting all CLs related to moving the eventlog, as they break Chromium tests.
Original issue's description:
> Move RtcEventLog object from inside VoiceEngine to Call.
>
> In addition to moving the logging object itself, this also moves the interface from PeerConnectionFactory to PeerConnection, which makes more sense for this functionality. An API parameter to set an upper limit to the size of the logfile is introduced.
> The old interface on PeerConnectionFactory is not removed in this CL, because it is called from Chrome, it will be removed after Chrome is updated to use the PeerConnection interface.
>
> BUG=webrtc:4741,webrtc:5603,chromium:609749
> R=solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org, tommi@webrtc.org
>
> Committed: https://crrev.com/1895526c6130e3d0e9b154f95079b8eda7567016
> Cr-Commit-Position: refs/heads/master@{#13321}
TBR=solenberg@webrtc.org,tommi@webrtc.org,stefan@webrtc.org,terelius@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4741,webrtc:5603,chromium:609749
Review-Url: https://codereview.webrtc.org/2111813002
Cr-Commit-Position: refs/heads/master@{#13340}
In addition to moving the logging object itself, this also moves the interface from PeerConnectionFactory to PeerConnection, which makes more sense for this functionality. An API parameter to set an upper limit to the size of the logfile is introduced.
The old interface on PeerConnectionFactory is not removed in this CL, because it is called from Chrome, it will be removed after Chrome is updated to use the PeerConnection interface.
BUG=webrtc:4741,webrtc:5603,chromium:609749
R=solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1748403002 .
Cr-Commit-Position: refs/heads/master@{#13321}
Reason for revert:
It turns out this revert was not necessary because the connection-state mapping for turn-turn connections was not done in connection.
Original issue's description:
> Revert of Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://… (patchset #5 id:120001 of https://codereview.webrtc.org/2041593002/ )
>
> Reason for revert:
> ReadyToSendMedia did not consider the new presumed_writable state.
>
> Original issue's description:
> > Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://codereview.webrtc.org/2000063003/ )"
> >
> > This reverts commit 72d41aa6da.
> >
> > New change made:
> > Do not reset the BWE when the new network route is not ready to send media.
> >
> > BUG=
> > R=pthatcher@webrtc.org, stefan@webrtc.org
> >
TBR=pthatcher@webrtc.org,stefan@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2094863003
Cr-Commit-Position: refs/heads/master@{#13282}
This reverts commit e30c272051 (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 825eb58d59.
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}
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}
Also refactor packet router to use a map rather than iterate over all
rtp modules for each packet sent.
BUG=webrtc:4311
Review URL: https://codereview.webrtc.org/1247293002
Cr-Commit-Position: refs/heads/master@{#9670}
Modify bitrate controller to update bitrate based on process call and not
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5794 4adac7df-926f-26a2-2b94-8c16560cd09d
This triggered an occasional TSAN failure in
CallTest.ReceivesPliAndRecoversWithNack e.g.:
http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1444/steps/memory%20test%3A%20video_engine_tests/logs/stdio
I managed to reproduce this locally and verified that reverting this CL
corrected it.
> Modify bitrate controller to update bitrate based on process call and not
> only whenever a RTCP receiver block is received.
>
> Additionally:
> Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
>
> Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
>
> Did not touch decrease logic, however since it can be triggered more often it
> may decrease much faster and closer to the original written cap of once every
> 300ms + rtt.
>
> Note:
> rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
> bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
>
> BUG=3065
> R=stefan@webrtc.org, mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/10529004TBR=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10079005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5775 4adac7df-926f-26a2-2b94-8c16560cd09d
- Move condition of 0 bps as max meaning 1gbps from SendSideBandwidthEstimation to BitrateController.
- Remove condition on bitrate=0 meaning bandwidth estimation off as that could only happen when no observers existed
and in which case the estimation would be ignored.
- Add MaybeTriggerOnNetworkChanged which only runs rate allocation if any of the dependent variables has changed
thus allowing to remove many of the bool returns that try to indicate if the estimation has changed which would not
be aware if the observers have changed.
- SendSideBandwidthEstimation now has a UpdateBitrate and has clear code paths to which calls update bitrate.
- Changes in enforce_min_bitrate so the 10kbps min is set from the BitrateController and not from the outside this keep valid as observers are changed.
R=henrik.lundin@webrtc.org, stefan@webrtc.org
BUG=3065
Review URL: https://webrtc-codereview.appspot.com/10189004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5752 4adac7df-926f-26a2-2b94-8c16560cd09d
The new test is based upon the exisiting rampup test, but also adds
a low-rate period. The main purpose of the test is to verify the
SuspendBelowMinBitrate functionality, which must be enabled for the
test to pass.
The CL also adds a change to the min bitrate in the send-side bandwidth
estimator when SuspendBelowMinBitrate is enabled.
An anonymous namespace is added around the StreamObserver classes
in the test to avoid silent linker conflicts that could happen
otherwise.
Note: this CL depends on https://webrtc-codereview.appspot.com/9049004/
BUG=2636
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9059004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5646 4adac7df-926f-26a2-2b94-8c16560cd09d
Changing to using strategy classes rather than having two different
derived classes of BitrateControllerImpl. This enables run-time switching
of the strategy, which is now possible through a new API. The reason is
that it must fit the current design of ViE.
BUG=2436
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2789004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5028 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL implements an alternative to the bitrate clamping that is done
in BitrateControllerImpl. The default behavior is unchanged, but if
the new algorithm is enabled the behavior is as follows:
When the new bitrate is lower than the sum of min bitrates, the
algorithm will give each observer up to its min bitrate, one
observer at a time, until the bitrate budget is depleted. Thus,
with this change, some observers may get less than their min bitrate,
or even zero.
Unit tests are implemented.
Also fixing two old lint warnings in the affected files.
This change is related to the auto-muter feature.
BUG=2436
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2439005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5007 4adac7df-926f-26a2-2b94-8c16560cd09d
