Sometimes the blurred value gets to be a little above 255 because of
floating point errors. This prevents the header from being sent, losing
1 second of information. This can easily be prevented with the changes
in this CL.
Bug: webrtc:358039777
Change-Id: Ibad1c8f41272260e28fe58557c623e52a6af8294
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376740
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Cr-Commit-Position: refs/heads/main@{#43906}
C++ version of
https://jsfiddle.net/fippo/ypj6mshr/3/
BUG=webrtc:360058654
Change-Id: Ieb6a149601093cafae337213d3e2b3b0bfc77831
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377322
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@{#43904}
This was a killswitch for AV1E_SET_MAX_CONSEC_FRAME_DROP_MS_CBR. The feature has been enabled for over six months and has proven to be working.
Bug: webrtc:351644568
Change-Id: Ifa02e72284c562298e3e5560dbc27f28a9e02819
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375863
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43903}
At some point this code path was used for the
WebRTC-VP8ConferenceTemporalLayers experiment, but that has been
deleted.
The API does not allow creating more than 3 temporal layers so this
should be dead code and deleting it causes no test failures.
Bug: None
Change-Id: Ie13bc09a7af996d081ab5702d1bb8d17c6021ce4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377300
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43900}
The dcSCTP receiver was advertising available window space (arwnd) based
solely on payload bytes, while the sender's rwnd estimation included
packet headers. This mismatch caused the sender to underestimate the
receiver's available buffer, potentially leading to reduced throughput.
This commit resolves the issue by ensuring both sender and receiver use
payload bytes, as headers have been removed on the receiver side while
in the reassembly queue.
Bug: webrtc:396373001
Change-Id: I508419efb09cabf2fb011f952f5f4a06586a4019
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377122
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43899}
Update to use similar bitrate limits as VP9, depending on whether QP
from encoder is trusted or not.
Bug: chromium:392060821
Change-Id: I305182fecf7acfe84dbd2e049f9ce712a7a30ede
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376762
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43898}
To reduce latency when delivering messages on channel with low traffic
volume and with packet loss, where retransmissions are not driven by
fast retransmit but by T3-RTX timer, set the I-SACK bit (RFC7053) when
the congestion window is low.
Note that RFC7053 doesn't have to be negotiated, as is explained in
https://www.rfc-editor.org/rfc/rfc7053.html#section-6, and if the
receiver doesn't support it, it will delay SACKs as is done today.
When T3-RTX fires, the congestion window will be set to one MTU and any
future sent message will only send one MTU's worth of data before waiting
for the receiver's SACK until more data is sent. Delayed SACK, which is
normally used, could delay the next packet from being sent unecessarily
long. Setting I-SACK when the congestion window is small will make the
receiver always send a SACK for every received packet with a DATA chunk
in it. By not setting it always, it will not affect the packet rate when
the channel is fully utilized.
This modification improves latency in the aforementioned situations
without significantly affecting bandwidth. While this change increases
SACK frequency in specific scenarios, the impact on overall network load
is expected to be minimal.
Bug: webrtc:396080535
Change-Id: If4a5aa960969f1385c9ea59baa7e2d52caf25626
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377140
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43897}
Follow-up to
https://webrtc-review.googlesource.com/c/src/+/375847
moving to a big outer loop over formats instead of calling the inner loop with single-element arrays.
BUG=webrtc:360058654
Change-Id: I7d263c1014d80f2312bf93595ee8e8ef9c4e7953
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376081
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43896}
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}
