The limit we put on probing is a bit too conservative now. If an
allocation limit is set, this CL allows probing up to 2x the current
max allocation limit.
This better handles overshooting when networks actually have the
capacity to allow bursts.
Bug: webrtc:10070
Change-Id: I0003f6b22512c13b6a83c1934952a2c3a2b70b48
Reviewed-on: https://webrtc-review.googlesource.com/c/112905
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25888}
This fixes an issue where SendSideCongestionControllerTest.OldFeedback
calls a function that posts a task on a TaskQueue and immediately after
changes the mocked observer that is called from that task.
Bug: webrtc:10056
Change-Id: Ib1cca5bf695482e75106bfc715662e4f76c381d9
Reviewed-on: https://webrtc-review.googlesource.com/c/112940
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25882}
Fixes the ENR threshold used in the dominant nearend detection when
the kill-switch WebRTC-Aec3UseLegacyNormalSuppressorTuning is pulled.
Bug: webrtc:8671,chromium:911141
Change-Id: I30ee58009633b3a9e12eff692226baada624a049
Reviewed-on: https://webrtc-review.googlesource.com/c/112903
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25880}
The current code assumes that layers are ordered from the smallest
to the largest.
If that assumption is broken and the last layer is smaller than the
others, all layers that are bigger will be scaled up.
Bug: webrtc:10069
Change-Id: Iff87ddba741d5dfe3d0cc25a8f75d898a417eec7
Reviewed-on: https://webrtc-review.googlesource.com/c/112460
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25878}
1. Make |output_period_ms_| optional, so as to clarify where
it gets assigned a value. (I.e. the value set by the ctor
is not retained.)
2. Some extra const modifiers.
Bug: webrtc:8111
Change-Id: I9f3ad7ff763cfbc9c9385f7fd4325ba696772765
Reviewed-on: https://webrtc-review.googlesource.com/c/112588
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25877}
This is a reland of a4dcb749fbbc83a874d4e2c65de5a98465d3e200
Original change's description:
> Fix output period in RtcEventLogImpl
>
> RtcEventLogImpl::StartLogging() was ignoring one of its parameters.
> This CL fixes the issue.
>
> Bug: webrtc:10082
> Change-Id: Ie1790c1a7299748dabe99909d967384ad9895635
> Reviewed-on: https://webrtc-review.googlesource.com/c/112586
> Reviewed-by: Björn Terelius <terelius@webrtc.org>
> Commit-Queue: Elad Alon <eladalon@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#25858}
Bug: webrtc:10082
Change-Id: I783fba84aa35e489f6235538c624b19f2f98a962
Reviewed-on: https://webrtc-review.googlesource.com/c/112860
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25876}
RtcEventLogImpl::task_queue_ is a std::unique_ptr<rtc::TaskQueue>.
When a unique_ptr is destroyed, it first sets its internal pointer
to point to null, and only then invokes the destructor of that
object. However, the code in RtcEventLogImpl relies on
rtc::TaskQueue's property, that its destructor blocks on executing
tasks.
We solve by manually invoking the destructor, and only resetting
the internal pointer thereafter. In theory, we could have changed
the unique_ptr to a raw pointer at this point. We avoid that, so
as to keep the ownership clearer to readers of the code.
Bug: webrtc:10085
Change-Id: I54bbf5d6bae019757ca2e31ee960d558058ccc42
Reviewed-on: https://webrtc-review.googlesource.com/c/112598
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25875}
See https://ci.chromium.org/p/chromium/builders/luci.chromium.webrtc/WebRTC%20Chromium%20Mac%20Tester
First, we figured that "ba2840c Various VP9 high fps fixes by Ilya Nikolaevskiy" was the cause and it was reverted but it did not help.
We must now try the other CL which had done changed in VP9.
Revert "Reland Profile 2 to default profiles"
This reverts commit 4c0cc5bc5fa027b9392ff2886e731bea3aac7602.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Reland Profile 2 to default profiles
>
> This is a reland after chrome browser tests are updated.
>
> Bug: webrtc:9376
> Change-Id: I818bf5d447da7901ffe49f2c452decb89196e829
> TBR: niklas.enbom@webrtc.org
> Reviewed-on: https://webrtc-review.googlesource.com/c/112060
> Reviewed-by: Emircan Uysaler <emircan@webrtc.org>
> Commit-Queue: Emircan Uysaler <emircan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#25778}
TBR=emircan@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:9376
Change-Id: I3eb935c08341ce51fa16717ed7b3be5f5253aa2f
Reviewed-on: https://webrtc-review.googlesource.com/c/112597
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25874}
Explicitly say "_compile_" for ARM and Clang and GCC.
Explicitly say "_arm_" for mobiles.
Explicitly say "_x86_" for Windows.
Fill in some gaps where both tester and compile-only bots are viable.
Also remove unused "experimental" tryjobs.
No-Try: True
Bug: webrtc:10072
Change-Id: Ib22e0518fc1e600b237c3c687994f27c7e88b8b3
Reviewed-on: https://webrtc-review.googlesource.com/c/112585
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Oleh Prypin <oprypin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25872}
kInvalid does not have a corresponding entry in the standard is therefore removed.
kUNSPECIFIED should be used instead.
Bug: webrtc:8651
Change-Id: Iee8cd85830aedaa4a9102251121b9975d40fa5e2
Reviewed-on: https://webrtc-review.googlesource.com/c/112421
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25871}
This change introduces a new class BufferedFrameDecryptor that is responsible
for decrypting received encrypted frames and passing them on to the
RtpReferenceFinder. This decoupling refactoring was triggered by a new
optimization also introduced in this patch to stash a small number of
undecryptable frames if no frames have ever been decrypted. The goal of this
optimization is to prevent re-fectching of key frames on low bandwidth networks
simply because the key to decrypt them had not arrived yet.
The optimization will stash 24 frames (about 1 second of video) in a ring buffer
and will attempt to re-decrypt previously received frames on the first valid
decryption. This allows the decoder to receive the key frame without having
to request due to short key delivery latencies. In testing this is actually hit
quite often and saves an entire RTT which can be up to 200ms on a bad network.
As the scope of frame encryption increases in WebRTC and has more specialized
optimizations that do not apply to the general flow it makes sense to move it
to a more explicit bump in the stack protocol that is decoupled from the WebRTC
main flow, similar to how SRTP is utilized with srtp_protect and srtp_unprotect.
One advantage of this approach is the BufferedFrameDecryptor isn't even
constructed if FrameEncryption is not in use.
I have decided against merging the RtpReferenceFinder and EncryptedFrame stash
because it introduced a lot of complexity around the mixed scenario where some
of the frames in the stash are encrypted and others are not. In this case we
would need to mark certain frames as decrypted which appeared to introduce more
complexity than this simple decoupling.
Bug: webrtc:10022
Change-Id: Iab74f7b7d25ef1cdd15c4a76b5daae1cfa24932c
Reviewed-on: https://webrtc-review.googlesource.com/c/112221
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25865}
This reverts commit a4dcb749fbbc83a874d4e2c65de5a98465d3e200.
Reason for revert: Speculative revert. Tsan failure has been consistently generated after this CL.
Original change's description:
> Fix output period in RtcEventLogImpl
>
> RtcEventLogImpl::StartLogging() was ignoring one of its parameters.
> This CL fixes the issue.
>
> Bug: webrtc:10082
> Change-Id: Ie1790c1a7299748dabe99909d967384ad9895635
> Reviewed-on: https://webrtc-review.googlesource.com/c/112586
> Reviewed-by: Björn Terelius <terelius@webrtc.org>
> Commit-Queue: Elad Alon <eladalon@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#25858}
TBR=eladalon@webrtc.org,terelius@webrtc.org
Change-Id: I6b79c207d537ab6ca44bb418958854acebc886ac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10082
Reviewed-on: https://webrtc-review.googlesource.com/c/112740
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25864}
RtcEventLogImpl::StartLogging() was ignoring one of its parameters.
This CL fixes the issue.
Bug: webrtc:10082
Change-Id: Ie1790c1a7299748dabe99909d967384ad9895635
Reviewed-on: https://webrtc-review.googlesource.com/c/112586
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25858}
This is the first step in moving the metadata and eventually replacing
VideoEncoderFactory::QueryVideoEncoder with VideoEncoder::GetEncoderInfo.
Bug: webrtc:10065
Change-Id: If925b895718e1b1225d2cf49bede1adb3ff281b8
Reviewed-on: https://webrtc-review.googlesource.com/c/112285
Commit-Queue: Mirta Dvornicic <mirtad@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25856}
Needed for coming cls to be able to use rtc_base/timeutils.h, which
shouldn't be included by api/ headers.
Bug: webrtc:9719
Change-Id: Ia36c0a9218ad505e1eb4f2d9c26d44d5673c2632
Reviewed-on: https://webrtc-review.googlesource.com/c/112580
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25855}
Conversion to kbps will fail if the estimate is lower than the deviation
estimate * 3, since that would produce a negative value.
Bug: webrtc:9718
Change-Id: I83b52acd476d90b1f22c9db9894fa26c9a3e8e17
Reviewed-on: https://webrtc-review.googlesource.com/c/112560
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25854}
By explicitly checking that the template argument is arithmetic, we
avoid exposing internal implementation details in the error message.
Bug: webrtc:9709
Change-Id: Ib1c4b46076af36fe0c4aead968487bb441d03b9a
Reviewed-on: https://webrtc-review.googlesource.com/c/112422
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25853}
With Retina monitor connected, OSX and Win10 work differently. OSX will
use logical pixel to cursor location and physical pixel to cursor image.
And Win10 will always use logical coordinate. So the processing in this
patchset should only be applied to OSX only.
Bug: chromium:909784
Change-Id: I038e7769d101fbc3efe08b4739204d523255b609
Reviewed-on: https://webrtc-review.googlesource.com/c/112523
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25850}
This prepares for future refactoring of rate controller.
Bug: webrtc:9718
Change-Id: I425c8c547399bda98b4271a0d24a0bb7ee06bc13
Reviewed-on: https://webrtc-review.googlesource.com/c/112420
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25846}
The UWP toolchain code appears to be broken with clang, so let's see
if we have better luck with MSVC.
Bug: webrtc:10050
Change-Id: If8d29e7a95a0780c310ccd665c99d7a3add1016a
Reviewed-on: https://webrtc-review.googlesource.com/c/112290
Reviewed-by: Oleh Prypin <oprypin@webrtc.org>
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25841}
