This CL removes the split of "desktop_capture" in 2 build targets
(one for C++ and one for Obj-C++) by moving the C++ part to
"desktop_capture" itself and keeping the Obj-C++ variant but allowing
it to include .h files that are also part of "desktop_capture".
This removes the build cycle between the two targets (which conceptually
are the same target).
Clients should never depend on "desktop_capture_objc", which will
be linked by "desktop_capture" when needed.
Bug: b/36882554
Change-Id: Id219a15e549275870c54375c07f00cfe704ab7cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266743
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Oleh Prypin <oprypin@google.com>
Cr-Commit-Position: refs/heads/main@{#37337}
The tests check that the various scalability mode are supported
and the frames are marked properly by the encoder with their
spatial and temporal index.
The same information is then checked on the receiving side.
A new member is added on EncodedImage to store the temporal index,
and is filled by the encoders and retreived by the ref finder
objects on the decoding side.
Bug: webrtc:11607
Change-Id: I7522f6a6fc5402244cab0c4c64b544ce09bc5204
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260189
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37303}
When the `WebRTC-Audio-TransientSuppressorVadMode-RnnVad` field trial
is set, APM now uses (i) its RNN VAD sub-module to compute the voice
probability, (ii) that probability for TS and (iii) a temporally
delayed version of it for AGC2 (the delay introduced by TS is taken
into account).
Bug: webrtc:13663
Change-Id: Ic0f245c3f00d318c19bb01d3dbc2d5176c90f851
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266362
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37291}
Add a VoiceActivityDetectorWrapper submodule in AudioProcessingImpl
and enable injecting speech probability into GainController2.
Bug: webrtc:13663
Change-Id: I05e13b737d085b45ac8ce76660191867c56834c2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265166
Commit-Queue: Hanna Silen <silen@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37275}
When a display uses a scale factor (different than 1.0) the previous
cursor position is not properly cleared during a CRD connection on
ChromeOS (see b/235191365).
The issue was that the fix for crbug.com/1323241 does not take device
scaling into account, so that fix would incorrectly not mark the
previous location of the mouse cursor as modified.
Adding proper boundary checks is hard and risky though, as the way the
position of the mouse cursor is reported seems to be platform dependent
(ChromeOS vs Linux vs ...).
So because crbug.com/1323241 only solves a theoretical crash that is rarely if
ever hit in the field, I decided to for now undo the fix for crbug.com/1323241.
A proper boundary check can then later be introduced without any pressure from
a looming release
Bug: chromium:1323241
Bug: b/235191365
Fixed: b/235191365
Test: Manually deployed
Change-Id: Ib09b6cc5e396bd52538332edfc4395ed80c6786e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265391
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Joe Downing <joedow@google.com>
Commit-Queue: Jeroen Dhollander <jeroendh@google.com>
Cr-Commit-Position: refs/heads/main@{#37274}
Make use of "persist_mode" option in ScreenCast portal to restore
previously selected screen/window and avoid picking it again in yet
another xdg-desktop-portal dialog.
Bug: webrtc:13429
Change-Id: I3a0068091c2dd38003a7dff3f82b9cdb2ccd0f42
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263901
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37257}
422 10 bit format is called I210 in the code and implemented in I210Buffer, and 420 10-bit format format is using is using the already existing I010 format and implemented in I010Buffer.
Bug: webrtc:13826
Change-Id: I6b6ed65b9fbb295386ea20f751bd0badc49ef21b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256964
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37252}
increasing precision since summing up rounded values leads to
a rounding error, in particular for small frames which take very
little time to decode.
BUG=webrtc:12526,webrtc:13756
Change-Id: I647c702808856a002c746ed9f115aa9bcaddc1f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262810
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/main@{#37249}
This reverts commit 6e4d7e606c4327eaa9298193e22794fcb9b30218.
Reason for revert: Still breaks downstream build (though in a different way this time)
Original change's description:
> Reland "Delete old Android ADM."
>
> This is a reland of commit 4ec3e9c98873520b3171d40ab0426b2f05edbbd2
>
> Original change's description:
> > Delete old Android ADM.
> >
> > The schedule move Android ADM code to sdk directory have been around
> > for several years, but the old code still not delete.
> >
> > Bug: webrtc:7452
> > Change-Id: I0f75c680f71f0b2ce614de6cbd9f124c2a59d453
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264620
> > Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
> > Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
> > Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#37174}
>
> Bug: webrtc:7452
> Change-Id: Icabad23e72c8258a854b7809a93811161517266c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265872
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Commit-Queue: Björn Terelius <terelius@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37236}
Bug: webrtc:7452
Change-Id: Ide8fbd55fadd7aed9989053afff7c63c04f1320f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266023
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Owners-Override: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37242}
This is a reland of commit 4ec3e9c98873520b3171d40ab0426b2f05edbbd2
Original change's description:
> Delete old Android ADM.
>
> The schedule move Android ADM code to sdk directory have been around
> for several years, but the old code still not delete.
>
> Bug: webrtc:7452
> Change-Id: I0f75c680f71f0b2ce614de6cbd9f124c2a59d453
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264620
> Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
> Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37174}
Bug: webrtc:7452
Change-Id: Icabad23e72c8258a854b7809a93811161517266c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265872
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37236}
This is the first CL out of three to make the low-latency stream signaling
explicit. At the moment this is done by setting the render time to 0.
There's a dependency between Chromium and WebRTC which is why this is
split into three CLs to not break any existing functionality.
Bug: chromium:1327251
Change-Id: Ie6b268746d587a99334485db77181fb2c6e9b567
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264502
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37225}
When DMA-BUFs are used, sometimes stride we get from PipeWire might
contain additional padding, but after we import the buffer, the stride
we used is no longer relevant and we should just calculate it based on
width.
Bug: chromium:1333304
Change-Id: Id4300550f0b3c539ddd749e9285f525d4f816b80
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265384
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37195}
The method can be used to ensure packets reported to NetworkStateEstimator include transport overhead.
Change-Id: I30f0271aac82633893660c61ea59e3b7c2cf9f31
Bug: webrtc:10742
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265405
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37179}
A recent cleanup cl (r36900) had an unintended side-effect.
If the queue-time limit is expected to be hit, we adjust the pacing
bitrate up to make sure all packets are sent within the nominal time
frame.
However after that change we stopped adjusting the pacing rate back to
normal levels when queue clears - at least not until the next BWE
update (which is fairly often - but not immediate).
This CL fixes that, and also makes sure whe properly update the
adjusted media rate on enqueu, dequeue and set rate calls.
Bug: webrtc:10809
Change-Id: If00dc35169f1a1347fea6eb44fdb2868282ed3b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265387
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37178}
The schedule move Android ADM code to sdk directory have been around
for several years, but the old code still not delete.
Bug: webrtc:7452
Change-Id: I0f75c680f71f0b2ce614de6cbd9f124c2a59d453
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264620
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37174}
This reverts commit 0ba10283fb3cbdf1cedea79d84e4bc3b720da6a1.
Reason for revert: This workaround is no longer needed, as the libyuv team has already fixed the underlying issue (in b/234824290)
Original change's description:
> Fix memory corruption in BasicDesktopFrame::CopyTo
>
> This memory corruption happens inside libyuv::CopyPlane()
> on platforms that support AVX. I opened b/234824290 so the libyuv team
> can investigate and fix this, but in the mean time we need to get this
> fixed asap as this is causing crashes on both M102 (which is released to
> stable) and M103 (which has this issue marked as beta blocking).
>
> Fixed: b/234824290
> Fixed: chromium:1330019
> Test: Manually reproduced on zork board
> Change-Id: I6bfd1e089020dfb23d974d3912d45c01a4e5ce26
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265041
> Auto-Submit: Jeroen Dhollander <jeroendh@google.com>
> Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#37121}
Fixed: b/234824290
Fixed: chromium:1330019
Change-Id: Iafc0eac651fbc7a7fce5092306b12c4377248839
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265165
Auto-Submit: Jeroen Dhollander <jeroendh@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Frank Barchard <fbarchard@google.com>
Cr-Commit-Position: refs/heads/main@{#37142}
This CL introduces PacketQueue::SizeInPacketsPerRtpPacketMediaType
keeping track of the number of packets in the queue per
RtpPacketMediaType.
The TaskQueuePacedSender is updated not to apply slack if the queue
contains any kRetransmission or kAudio packets. The hope is that not
slacking retransmissions will make the NACK/retransmission regression
of the SlackedPacer experiment go away. Wanting to not slack audio
packets is unrelated to the regression but a sensible thing to due
since audio is highest priority.
This CL does not change anything when the SlackedPacer experiment is
not running, since if its not running then none of the packets are
slacked.
Bug: webrtc:14161
Change-Id: I1e588599b6b64ebfd7d890706b6afd0b84fd746d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265160
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37139}
This memory corruption happens inside libyuv::CopyPlane()
on platforms that support AVX. I opened b/234824290 so the libyuv team
can investigate and fix this, but in the mean time we need to get this
fixed asap as this is causing crashes on both M102 (which is released to
stable) and M103 (which has this issue marked as beta blocking).
Fixed: b/234824290
Fixed: chromium:1330019
Test: Manually reproduced on zork board
Change-Id: I6bfd1e089020dfb23d974d3912d45c01a4e5ce26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265041
Auto-Submit: Jeroen Dhollander <jeroendh@google.com>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37121}
When the slacked pacer experiment is enabled the next pacing opportunity
may be a full tick (~16 ms) from now. Add a flag to allow experimenting
with a burst interval (= 16 ms?) such that we can send bursts in
MaybeProcessPackets.
A common use case would be that EnqueuePackets triggers
MaybeProcessPackets when we are off-tick but we'd still like to create
an immediate burst instead of waiting for the next tick or two for that
to happen.
Bug: webrtc:14152
Change-Id: Ib0ed8312cb7d53b80f3520fff3a6e3bbb5a93fd1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264985
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37116}
