Changing to an index for-loop (instead of using std::max_element & std::distance) tracking even & odd elements separately allows the compiler to produce code with less pipeline stall.
Bug: None
Change-Id: Iaa3e820a3a3b61e2eb276f0dac9106c848db1891
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/240061
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Christian Schuldt <cschuldt@google.com>
Cr-Commit-Position: refs/heads/main@{#35729}
When screencast session is closed, there won't be any other stream we
can reconnect to and in that case we are supposed to disconnect our
stream to prevent accidentally connecting to any other stream in case it
gets assigned same node ID from PipeWire
Bug: webrtc:13429
Change-Id: Iec8e93a108c789c32cb93e1460e693fabc247491
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/241086
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35728}
ChromeOS uses int64_t for its IDs (see display::Display::id()) so there is a potential for errors if casting (or attempting to hash and translate the larger ID to a smaller ID and vice versa).
Instead we should update the desktop_capture component to use int64_t natively.
Bug: webrtc:13571
Change-Id: I78b3456ce11b75755b90863a02f8c6455c63acf9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246240
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jeroen Dhollander <jeroendh@google.com>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#35724}
Updates all webrtc code, to have a small followup cl to just add the
"explicit" keyword. Patchset #24 passed all webrtc tests, with explicit.
Bug: webrtc:13464
Change-Id: I39863d3752f73209b531120f66916dc9177bf63a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242363
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35718}
the new spelling is more standard and more compact, in particular doesn't need extra include and thus dependency
Bug: None
Change-Id: Iaea69d2154e4d9eff2468514f5734cb3fe016ff8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/245080
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35709}
We need to check the PipeWire server version in order to be sure we can
advertise DMA-BUF support, because it doesn't mean the version of
PipeWire we built our code against will run against the same PipeWire
version. Also do not announce DMA-BUF support for PipeWire older than
0.3.24 as this will not be working. For DMA-BUF modifiers support we
need the PipeWire version to be at least 0.3.33 on both sides (client
and server). Last but not least minor fix is not to announce
modifier-less DMA-BUF support when we don't have required extension.
Bug: chromium:1233417
Change-Id: If2a0a2328b893ccbeab61cb4039029b8a113a1ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246440
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35699}
This reverts commit e51937dfc5567b6ce53bd1211799dbdaff8b268e.
Reason for revert: This change was not intended to land yet.
Original change's description:
> PipeWire capturer: advertise DMA-BUF support when really supported
>
> We need to check the PipeWire server version in order to be sure we can
> advertise DMA-BUF support, because it doesn't mean the version of
> PipeWire we built our code against will run against the same PipeWire
> version. Also do not announce DMA-BUF support for PipeWire older than
> 0.3.24 as this will not be working. For DMA-BUF modifiers support we
> need the PipeWire version to be at least 0.3.33 on both sides (client
> and server). Last but not least minor fix is not to announce
> modifier-less DMA-BUF support when we don't have required extension.
>
> Bug: chromium:1233417
> Change-Id: Iee035d61bbc9d5878621555c365751ee4edc9d28
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239649
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Jan Grulich <grulja@gmail.com>
> Cr-Commit-Position: refs/heads/main@{#35696}
TBR=tommi@webrtc.org,jansson@google.com,sprang@chromium.org,grulja@gmail.com,mfoltz@chromium.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I2aff8ca2650aa14932c0bd15bdc4f30f406f91de
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1233417
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246401
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Christoffer Jansson <jansson@google.com>
Commit-Queue: Christoffer Jansson <jansson@google.com>
Cr-Commit-Position: refs/heads/main@{#35697}
We need to check the PipeWire server version in order to be sure we can
advertise DMA-BUF support, because it doesn't mean the version of
PipeWire we built our code against will run against the same PipeWire
version. Also do not announce DMA-BUF support for PipeWire older than
0.3.24 as this will not be working. For DMA-BUF modifiers support we
need the PipeWire version to be at least 0.3.33 on both sides (client
and server). Last but not least minor fix is not to announce
modifier-less DMA-BUF support when we don't have required extension.
Bug: chromium:1233417
Change-Id: Iee035d61bbc9d5878621555c365751ee4edc9d28
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239649
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#35696}
Currently some RTPVideoHeaders are not filled with width and height
information, such as AV1. If we dump the stream with command line
“--force-fieldtrials=WebRTC-DecoderDataDumpDirectory/./”, and if
width and height are 0, it will crash soon.
This CL aims to avoid crashing when the |encoded_image._encodedWidth|
and |encoded_image._encodedHeight| are 0.
Bug: webrtc:13491
Change-Id: Ie5af58c03f09a9784ed67943dc5b5959850b4368
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242500
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35576}
Manually unrolling the multiply-and-accumulate loop of the matched filter allows interleaving of instruction, which gives a significant saving.
Bug: None
Change-Id: Ie7a7d92bd453d81e9dd61812781a7b6d62e1f1f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/240321
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Christian Schuldt <cschuldt@google.com>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35566}
Important: This change does not in any way affect echo cancellation or standardized stats. The user audio experience is unchanged. Only non-standard stats are affected. Echo return loss metrics are unchanged. Residual echo likelihood {recent max} will no longer be computed by default.
Important: The echo detector is no longer enabled by default.
API change, PSA: https://groups.google.com/g/discuss-webrtc/c/mJV5cDysBDI/m/7PTPBjVHCgAJ
This CL removes the default usage of the residual echo detector in APM.
It can now only be used via injection and the helper function webrtc::CreateEchoDetector. See how the function audio_processing_unittest.cc:CreateApm() changed, for an example.
The echo detector implementation is marked poisonous, to avoid accidental dependencies.
Some cleanup is done:
- EchoDetector::PackRenderAudioBuffer is declared in one target but is defined in another target. It is not necessary to keep in the API. It is made an implementation detail, and the echo detector input is documented in the API.
- The internal state of APM is large and difficult to track. Submodule pointers that are set permanently on construction are now appropriately marked const.
Tested:
- existing + new unit tests
- audioproc_f is bitexact on a large number of aecdumps
Bug: webrtc:11539
Change-Id: I00cc2ee112fedb06451a533409311605220064d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239652
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35550}
Reducing pointer following. This will allow the compiler to optimize more efficiently with the "-fno-strict-aliasing" flag.
Bug: None
Change-Id: I8e2d841fa543b28c59eb08c654a2b0515ab39d69
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/241780
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Christian Schuldt <cschuldt@google.com>
Cr-Commit-Position: refs/heads/main@{#35548}
The frame cadence adapter previously resulted in unconditional
frame repeating at max FPS. Change this to slow down to an idle
rate (1 Hz) when quality convergence in all configured spatial
layers has been achieved.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: Ifa593dbf8a61aa29da20ac250da332734ae82791
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/241421
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35547}
kIvfHeaderSize is defined both inside of ivf_file_writer.cc and
ivf_file_reader.cc. This patch moves its definition into a header.
Bug: webrtc:13463
Change-Id: Ia6b2fcc3434f69a1e30a7dae7bf0c90547f11d98
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239722
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35540}
Unloading states and coefficients to local variables avoids excessive memory access when building with "-fno-strict-aliasing".
Bug: None
Change-Id: I90bf81ae794c21e9e41500c5040387cf67ebdd38
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/240320
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Christian Schuldt <cschuldt@google.com>
Cr-Commit-Position: refs/heads/main@{#35518}
FrameBuffer3 keep track of order, decodability and continuity of the inserted frames. Compared to FrameBuffer2 which schedule frames for decoding and is thread safe, FrameBuffer3 does not schedule decoding and is thread unsafe.
Change-Id: Ic3bd540c4f69cec26fce53a40425f3bcd9afe085
Bug: webrtc:13343
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238985
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35494}
This was a remenant leftover from a previous design, which was no longer
valid after the switch to TaskQueues. ReturnReason::kStopped was not
used at all, and so Timeout or FrameFound can be inferred from whether
the frame is null or not.
Bug: webrtc:13343, webrtc:13346
Change-Id: Ib0f847b1e1192e32ea11208e48f5a3892703521e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239651
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35490}
The pacer status is never changed unless MaybeProcessPackets() is
called. This CL removes the scheduler, and updates pacer status after
every MaybeProcessPackets().
Bug: webrtc:10809, webrtc:13417
Change-Id: Ib5f18decf44c1596c0a716d799600a72b2332abd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239120
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35489}
Changing to an index for-loop (instead of a range for-loop) allows the compiler (clang for x86 at least) to unroll it x2.
Bug: None
Change-Id: I9b9612a8513a06e8aa3b12ae39f6911217da55fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239741
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Christian Schuldt <cschuldt@google.com>
Cr-Commit-Position: refs/heads/main@{#35478}
There are cases for each of these getters where other code later takes
a reference to the passed object, meaning that these getters should be
returning a refptr. To prevent additional overhead from places that
simply access the getter to call additional methods without needing to
worry about taking a ref, the return values are converted to const refs.
Bug: webrtc:13465
Change-Id: Ib27969c7f5ef9d6aadf3c95ac171ae6e778cdbfa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239720
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35465}
