Also unifies the mock inheritance if they inherited from a ref counted
interface:
- it should only inherit from the interface
- it should use make_ref_counted
Bug: webrtc:14594
Change-Id: I7b0514b632ccd0798028b50f19812ac0a196e13c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262423
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38602}
This is to avoid passing delay based estimate value twice from send side bwe.
Bug: webrtc:12707
Change-Id: Idc77cf7c2f4ecc60ae1dcfead325320532e7a7ca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282864
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38600}
It appears to be still failing occasionally so add one more event
to verify streams connected successfully in order to verify whether
we sent and received buffers properly in the next step.
Bug: webrtc:14644
Change-Id: I08822b15452fc845d68cbff1b01ae6b6f7c1f486
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282842
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#38598}
Instead of disabling probing when the total allocated bitrate has
changed in goog_cc, it can be done via a new field trial parameter,
"probe_max_allocation". Not that the currently used flag
RateControlSettings::TriggerProbeOnMaxAllocatedBitrateChange() is per
default enabled and will be cleaned up in a follow up cl.
The field trial flag "skip_if_est_larger_than_fraction_of_max" now also
skip probing if the current estimate is larger than the currently max
allocated bitrate. ie, alr probing is skippe if the current estimate >
max configured bitrate or current estimate > max send bitrate of all
streams.
Bug: webrtc:14392
Change-Id: I2a09be39f85a9122410edd5acb1158ece12fca60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282860
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38597}
Add a few tests to get started on debugging.
The goal of this CL is to get the Fuchsia bots running the tests without infra specific issues. After landing this, failures will be in test framework files (e.g. test/testsupport folder) and WebRTC code.
Bug: b/232740856
Change-Id: I332607fe875334769e7dadf6696d878a23a7e69f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280440
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@google.com>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#38596}
Replace the use of MonoInputController::min_mic_level() with
MonoInputVolumeController::clipped_level_min() when estimating input
volume adjustment from clipping prediction. The adjustment is later
capped in MonoInputVolumeController::HandleClipping() using
clipped_level_min_ so no audio changes are expected from this change.
Bug: webrtc:7494
Change-Id: Ie26d0aa5cce3eeef06f70a281504889519bb5aca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282840
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38593}
Instead of trying to guess the state from the loss based estimator by
looking at the estimate, use the state.
Bug: webrtc:14392
Change-Id: Ibf6e762f02bfbfff175f2aa2bc98f45b1c5beb1a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282823
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38589}
This is to ensure Epoch is the same if transport switch to TCP or another transport.
First packet received will always be timestamped with rtc::TimeMicros.
Other packet timstamps will use the kernel timestamp as an offset from the first packet timestamp.
For BWE, it is important that there is not a large time base diff if transport change.
This change is protected by the experiment WebRTC-SCM-Timestamp.
Bug: webrtc:14066
Change-Id: Iaeb49831e7019e21601bc90895ac56003a54e206
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281000
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38587}
Using ::recvmsg ensure packet timestamp can then be read directly when reading the buffer
instead of a separate system call and should also work on Ios/Mac.
The same experiment field trial flag will be "WebRTC-SCM-Timestamp/enabled/" and is also planned to be used for fixing webrtc:14066
Bug: webrtc:5773, webrtc:14066
Change-Id: I8a3749e87c686aa18fcee947472c1b602a0f63c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279280
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38585}
Android video codec factories are expected to be synchronised with the native ones in terms on supported codecs. But before this change there were differences:
1. Native decoder factory keeps AV1 support behind RTC_DAV1D_IN_INTERNAL_DECODER_FACTORY while Android decoder factory advertises AV1 unconditionally;
2. Native encoder factory advertises AV1 if RTC_USE_LIBAOM_AV1_ENCODER is enabled while Android encoder factory never advertises AV1.
This CL synchronises the codecs set in Android factories with that of native factories by calling native factories from Android ones.
Bug: webrtc:13573, b/257272020
Change-Id: I99d801eda0c5f3400bac222b9b08d719f1a6ed72
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282240
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38583}
The Chromium implementation unfortunately has a rare deadlock.
Rather than patching that up, we're changing the metronome
implementation to be able to use a single-threaded environment
instead.
The metronome functionality is disabled in VideoReceiveStream2
construction inside call.cc.
The new design does not have listener registration or
deresigstration and instead accepts and invokes callbacks, on
the same sequence that requested the callback. This allows
the clients to use features such as WeakPtrFactories or
ScopedThreadSafety for cancellation.
The CL will be followed up with cleanup CLs that removes
registration APIs once downstream consumers have adapted.
Bug: chromium:1381982
Change-Id: I43732d1971e2276c39b431a04365cd2fc3c55c25
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282280
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38582}
ChannelManager has been deleted, these declaration should also be deleted.
Bug: webrtc:13931
Change-Id: I2739a0424f61d6e659cb694a3f51bb6b90911cf9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282520
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38579}
A few usages in ssl_stream_adapter_unittests are converted to make
sure the aliases are usable.
Next steps are:
- Change all usages inside WebRTC to the new form
- Deprecate the old API
- Remove the old API
Pipewire failures believed to be unrelated, so No-try.
No-try: true
Bug: webrtc:14632
Change-Id: I618551e61a05d53e524e97483d3c7cef59b88a25
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282221
Reviewed-by: Tomas Gunnarsson <tommi@google.com>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38577}
As the exposure of power efficient stats to JavaScript are limited as
to reduce the fingerprinting surface to getStats, a new RTCStatsMember
derivation, RTCLimitedStatsMember, was added in this change. This sets
the exposure criteria of the stat on the type, which keeps the size of
the RTCStatsMember class the same and allows for extension in the future
for new types of stat restrictions.
Bug: webrtc:14483
Change-Id: Ib0303050a112441ba2416fd5f004dd8be26b47ca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279021
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38576}
Previously, cleanup in GetCandidateBandwidthUpperBound in loss_based_bwe_v2.cc causes unbounded bandwidth estimate. It leads to many warning logs being printed out at loss_based_bwe_v2.cc:95.
However, the cleanup is still necessary because the param bandwidth_rampup_upper_bound_factor is not used in current launches.
To fix the infinite estimate, we set max_bitrate in loss based bwe, which is derived from goog_cc, and not allow the estimate to go above that value.
*** Original change description ***
* Revert "Probing integration in loss based bwe 2." (diepbp@webrtc.org)
* https://webrtc-review.googlesource.com/c/src/+/277400
***
Bug: webrtc:12707
Change-Id: If0cd16daba4a4941043a1610edca2a13c9564328
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281280
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38574}
This =default declaration has no effect other than to break designated
initialization in C++20 by making the type no longer an aggregate.
Bug: None
Change-Id: I20a4c285b7cbfed074291b9ee27c03aa29bada32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281960
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38573}
This is a reland of commit 38fcd58429b29c9474f1647efed7ebeb543c0637
Original change's description:
> Change default NetEq sample rate to 48k.
>
> This should avoid some resampling before any packets have been received given that the vast majority of devices use 48k sample rate and the most common codec is Opus (which we always decode in 48k).
>
> Bug: none
> Change-Id: Ie7baea57c3eb1b763a6460c3b06b56d67b2b258e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280662
> Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
> Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38536}
Bug: none
Change-Id: Id634799286f6d1f1eaf315ebe8e70de669d589db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281900
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38572}
Remove function declarations, members, and friend tests that are
no longer used. Reorder the member variables.
Bug: webrtc:7494
Change-Id: I8c24e2f4b9d9846e6d3fef4e2c998aa26f49f8c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282180
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38570}
The code for determining outbound-rtp.active assumed, as the spec says,
that we have one RtpEncodingParameters per RTP stream. Unfortunately
SVC is currently implemented as one RtpEncodingParameters per SVC
layer. This causes a discrepency where we do correctly only have one
outbound-rtp stats object, but the lookup to check whether or not we are
"active" needs to look at more than a single encoding.
The bug is that if SVC layers are {inactive, active, active} then
stats reports outbound-rtp.active: false. With this fix, active: true is
reported if ANY of the SVC layers are active.
For singlecast or simulcast this CL has no change in behavior. In these
cases we have the same number of outbound-rtp and encodings and a simple
ssrc lookup does work.
The fix is exercised by unit tests and has also manually been confirmed:
- Singlecast tested by https://jsfiddle.net/henbos/nvd6p4j1/.
- Simulcast tested by https://crbug.com/webrtc/14628#c11.
- SVC tested by Google Meet and chrome://webrtc-internals/.
Bug: webrtc:14628
Change-Id: Ib89945caf29c8f4b85dd8a1120dcf8279296e4a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282222
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38569}
Classes defined inside the class PeerConnectionE2EQualityTestFixture are replaced by the ones define in media_configuration.h.
Change-Id: I1c025ff10aacf8cbc3df9bfa742a40622fe0807a
Bug: webrtc:14627
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281860
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38568}
and do the resolution of rids to layers. This has no effect yet
since the simulcast encoder adapter (SimulcastEncoderAdapter::Encode), the VP8 encoder (LibvpxVp8Encoder::Encode) and the OpenH264 encoder (H264EncoderImpl::Encode) all generate a key frame for all layers whenever a key frame is requested on one layer.
BUG=chromium:1354101
Change-Id: I13f5f1bf136839a68942b0f6bf4f2d5890415250
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280945
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38565}
Replace the use of speech level target and digital gain maximum with speech level target range parameters.
Bug: webrtc:7494
Change-Id: I703756c5a3fbd330ed585e3f5b4ac3141d9ea6e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280943
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38563}
The builder is blocking Webrtc to Chromium roll. Nexus5X phones are going to be replaced with Pixels soon anyway. So there is no reason in trying to fix the bot now. Especially since it fails with infrastructure issus: `Failure [INSTALL_FAILED_OLDER_SDK]`
Bug: b/257742011
Change-Id: Id346663f35bcc5089c314d42c2724952dab658e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282224
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Auto-Submit: Andrey Logvin <landrey@google.com>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@google.com>
Cr-Commit-Position: refs/heads/main@{#38562}
The goal is to remove the dependency between PeerConfigurerImpl and PeerConnectionE2EQualityTestFixture so that PeerConfigurerImpl can be used in PeerConnectionE2EQualityTestFixture API.
Change-Id: I29ae44b9d0e39075d0c395ff9d9f8d313be12176
Bug: webrtc:14627
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281740
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#38560}
This is a reland of commit c1d5fda22c8ae456950c5549d22d099b478c67e2
Original change's description:
> Add documentation, tests and simplify webrtc::SimulatedNetwork.
>
> This CL increases the test coverage for webrtc::SimualtedNetwork, adds
> some more comments to the class and the interface it implements and
> simplify the logic around capacity and delay management in the
> simulated network.
>
> More CLs will follow to continue the refactoring but this is the
> ground work to make this more modular in the future.
>
> Bug: webrtc:14525, b/243202138
> Change-Id: Ib0408cf6e2c1cdceb71f8bec3202d2960c5b4d3c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278042
> Reviewed-by: Artem Titov <titovartem@webrtc.org>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Björn Terelius <terelius@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38388}
Bug: webrtc:14525, b/243202138, b/256595485
Change-Id: Iaf8160eb8f8e29034b8f98e81ce07eb608663d30
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280963
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38557}
After discussion on webrtc-core, this option is still thought to be
a Bad Idea in webrtc.
Bug: none
Change-Id: I15d0a6f7d6489b8bf37c1dfa31572139c9b85753
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281881
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38555}
In InputVolumeController/MonoInputVolumeController, set
min_digital_gain_db_ and disable_digital_adaptive_ to fixed values
ahead of replacing speech level target as well as digital gain
minimum and maximum with target range parameters.
In InputVolumeController, remove digital_adaptive_follows and
min_digital_gain_db from the config as they are no longer needed.
Bug: webrtc:7494
Change-Id: I1378b6e182224c41038c6d8c649e7a28961f73d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280962
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38554}
