Propagate field trials using Environment with intent to change various types, BasicPortAllocator in particular, to take Environment at construction.
Bug: webrtc:42220378
Change-Id: I488aa82aa606e38f16aa22a032c60f4d191ede72
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377040
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43887}
This field trial was enabled by default for a long while.
Bug: webrtc:42234783
Change-Id: If050f88a3649c43d895110f4f68160f020f854e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376421
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43885}
This test used a fixture to create the send queue, but that makes it
hard to construct them with different parameters in some tests.
This refactoring removes the test fixture and creates the queue in each
test, which improves test readability instead, as there will be no need
for remembering how it was created - that's given by each test now.
Bug: webrtc:393540127
Change-Id: I8d158b6ff57fe9cb03b2762d736cf79afbbb8283
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376100
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43880}
Using parameterized testing, ensure that every possible payload type
that can be negotiated via remote O/A continues to show up in the local
follow-up offer in a subsequent O/A exchange.
This was an attempt to reproduce https://crbug.com/395077842, however
we pass all combinations.
Bug: chromium:395077842
Change-Id: Id4fd6f07a0870c8cd80ff7cf419e21fd6e2dbade
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376862
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43876}
This is a reland of commit 1ad3e14e9981772554a848c5034c7c555680aef7
The original CL removes all sending streams since all codec types has
been attempted for encoding and we have no other codecs to fallback to.
However some downstream applications will still attempt to set the codec
preferences even all send streams have been removed.
As a result, we follow previous logic to keep the send streams, to avoid
the regression.
Original change's description:
> Follow codec preference order for sending codec fallback.
>
> When encoder selector is not enabled, currently we always fallback to
> VP8 no matter how the codec preference is setup. Update to follow codec
> preference order for the fallback.
>
> Bug: chromium:378566918
> Change-Id: Ia3fbfc9d407683ef7b3d6246af7e9ec58535dc89
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370707
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43566}
Bug: chromium:378566918, b/384725754
Change-Id: Ifd48b30b80ae51c3ede9391ed62e8ce408864aa0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374852
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43874}
Note that this needs to be done with a work directory that supports
fuzzer builds, otherwise IWYU will bail out with complaints about
find-bad-constructs and raw-ptr-plugin
Some manual work was required to resolve the TaskQueueFactory which
is forward-declared by environment which required a manual include
of the header file.
The DcSctp packet fuzzer was also updated use the
disable_checksum_verification option which was moved to the
DcSctpOptions struct.
vp9_encoder_references_fuzzer was trying to include libvpx includes
which had to be reverted.
BUG=webrtc:42226242
Change-Id: I9fdcf979e73fdee77106c4583faff21ca7abf19f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375840
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43873}
To minimize direct construction of BasicPortAllocator, network emulation manager api is changed to push toward injecting network dependencies to PeerConnectionFactory and let it create PortAllocator
Bug: webrtc:42232556
Change-Id: I0c86d797a97d543c2f033286281dc1145d4ef51b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376880
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43872}
That accessor forces test helpers to create BasicPortAllocator themself
rather than deligate such task to PeerConnectionFactory
Bug: webrtc:42232556
Change-Id: I262e032da110222198e6308f57a5e5f2d7ba4601
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376741
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43870}
Since the device_scale_factor is usually exposed as a float in chromium,
we want to keep it same here for consistency.
Bug: chromium:383946052
Change-Id: I8d055ca0fcac623f59dcf96eb3cee15efc23b2ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376700
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43869}
In all the other functions `monitor_id` is a global id from range [0..total monitor count), but each DxgiAdapterDuplicator always assumes that it gets a local id from range [0..adapter monitor count).
Bug: chromium:395807060
Change-Id: I4bb232ee5d83f09859534f813111446763fe9fc9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376840
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43867}
as the "upper range" is already filled and new codecs should prefer the
lower dynamic PT range.
drive-by: restore audio/red behavior too even though in practice it has
not changed.
BUG=chromium:391903235
Change-Id: Iefc78253bf0fe88567f9032059ead3c2557e36a1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376520
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43866}
Now that there is not requirement of base-heavy for H.265 simulcast, it
should follow VP9 on simulcast bitrate allocations per stream.
Bug: chromium:392060821
Change-Id: I245def7f27022a943a31e96a51552db7505b7546
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376620
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43865}
This way that emulated network may be injected into PeerConnectionFactoryDependencies
and thus would allow test code not to manually create BasicPortAllocator
Bug: webrtc:42232556
Change-Id: Ifac29e584e66d7e585e8c8d74959cba288c6ffe0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376500
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43864}
to unbreak the Chromium roll which bails out on
../../sdk/android/instrumentationtests/src/org/webrtc/GlRectDrawerTest.java:78: warning: [AssertEqualsArgumentOrderChecker] Arguments are swapped in assertEquals-like call
assertEquals(rgbaBuffer.remaining() % 4, 0);
BUG=None
Change-Id: I437de037ad45fb6779a03bde3851088ed81e1943
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375023
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43862}
This was generated by
Running
$ for i in test/network/*.cc; do ./tools_webrtc/iwyu/apply-include-cleaner $i; done
$ for i in test/network/*.h; do ./tools_webrtc/iwyu/apply-include-cleaner $i; done
$ python3 ./tools_webrtc/gn_check_autofix.py -C out/Default
manually removing <sys/socket.h> include as suspicious.
manually modifying test/DEPS file.
Bug: webrtc:42226242
Change-Id: Ifda037e1385996ac3b68190c7e30e5309356ebb1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376382
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43857}
This CL fixes two issues with the old way targetBitrate was reported:
1. The target is per encoder, i.e. per SSRC, but the old way to report
it was per sender and was approximately the sum of all encodings'
targetBitrate in most cases.
2. The old value did not come directly from the VideoBitrateAllocation
and tended to be greater than the sum of all targets (don't know
why).
We know the old value was wrong and the new value correct because
the actual bytes produced by the encoder closely matches the configured
target, which wasn't always the case with the old metric implementation.
Tested with unit tests and manually in Chrome by going to
https://henbos.github.io/codec-quality/src/index.html and ensuring
target ~= actual bytes produced. It also matches the debug logging of
video_stream_encoder.cc.
Bug: webrtc:42225524, chromium:392424845
Change-Id: I7a6f69e053ebc3fd972c2c4b7712750e721c0acc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376460
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43854}
When using GDI to capture windows, not only will the target window be
captured, but all owned windows of the target window will also be
captured, and the captured results of the owned windows will be drawn
onto the captured result of target window.
GDI (BitBlt or PrintWindow) cannot capture windows with WS_EX_LAYERED
attribute, so when the owned window has this attribute, the area of the
owned window in the result is black.
After modification, if the owned window has the WS_EX_LAYERED attribute,
it will not be captured or drawn.
Bug: webrtc:394380765
Change-Id: I5f0c7d31809a353377b0aa52452634b46247af5f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376360
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#43851}
Multiple derived classes duplcated that code, and one more fixture
can benefit from the same direct access to avoid saving reference to port allocator
Cleaned includes and build dependencies on the way, in particular left single build target that contains peer_connection_wrapper
Bug: webrtc:42232556
Change-Id: Ieb3d5449f3a0285230847716e33fb3b2d1b47882
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376300
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43847}
and make it less opus-specific.
BUG=None
Change-Id: I6fe2975ba6e45a3758fedc5b950de90e8d9df362
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375436
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43846}
This is to fix build error when we set use_libcxx_modules=true in
chromium.
Bug: chromium:40263312
Change-Id: I7dd87e43823f33f70c6c8e15f4c64df7d231f021
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376003
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Takuto Ikuta <tikuta@google.com>
Cr-Commit-Position: refs/heads/main@{#43845}
Useful for when creating aggregate stats objects, seems like an
oversight that we don't have it already.
Bug: None
Change-Id: Ied36afd2122464a81c7d725825353f9af59fe632
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376220
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43844}
This was needed because Android builds depended on chromium base which is not the case anymore.
Bug: None
Change-Id: I0de26ff61fe105c68a6d60def291c542f4b65a70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376240
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43843}
std::aligned_storage is deprecated in C++23, see linked bug. The only
webrtc usage (VoidUnion::inline_storage) employed the default Align
parameter (i.e. std::aligned_storage<Len>, not std::aligned_storage<Len,
Alignment>), which is defined as the largest alignment <= Len.
This patch replaces the usage with a char buffer of same size and
alignment alignof(std::max_align_t). In theory, this might increase
alignment and use more memory. In practice, local testing in my
machines showed no behavior change, since Len =
kInlineStorageWords * sizeof(uintptr_t) = 32 > 16 (maximum alignment
on linux x86_64) > 8 (maximum alignment on mac arm64).
Bug: chromium:388068052
Change-Id: If08b69f7a5ff7b716a66c8703e31eb5d4de14431
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/373800
Commit-Queue: Victor Vianna <victorvianna@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Victor Vianna <victorvianna@google.com>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43842}
Adds test coverage for the following mitigations (need both to pass):
1. https://webrtc-review.googlesource.com/c/src/+/375847
2. https://webrtc-review.googlesource.com/c/src/+/376022
Like the comment says, this is neither mandated by the spec or
guaranteed, but when the number of codecs is quite small like it is in
this test it will be true for all RTX codecs.
Bug: webrtc:360058654
Change-Id: Ib73cea59d06a62390dd039eb2dc04677d6178460
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375865
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43841}
Some methods used a weak peer_connection reference directly,
supposedly causing crashes.
Now, both peer_connection and delegate are captured as
strong references and validated before use for consistency.
Bug: webrtc:393263500
Change-Id: I0ab39acf7097d4c8082d05749b37b6d4998f9aa7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375880
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Yury Yarashevich <yura.yaroshevich@gmail.com>
Cr-Commit-Position: refs/heads/main@{#43839}
