OpenH264 cannot be usually used everywhere as it's proprietary and for
that reason it's usually disabled or apps using it are not allowed to be
available in default installations. Using system OpenH264 option allows
us to use e.g. noopenH264, that can be present in default installations
and later replaced by OpenH264 installed from 3rd party repository.
Bug: webrtc:14717
Change-Id: I015aacdb48c0636935f611459f0c9a6aa74a8f94
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349301
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#42509}
BWE logging has as far as I know know been used for a long time. RTC event logs are the prefered method of logging.
Removed since it causes some BUILD pain.
For debugging the metrics API https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/test/metrics/ can be used instead.
Bug: webrtc:343347276
Change-Id: I046b58d880faabfadbc22269b0392fdd644155fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/352602
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42402}
Abseil deps are automatically filtered and replaced by the catch-all
Abseil dependency when built within Chromium. This removes the need to
have special handling for Abseil dependencies in our rules and facilitates
tooling.
Bug: webrtc:341803749
Change-Id: I07425e85d9eeccb66ad423fb1db8b59527a0956a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/351003
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42365}
This is the first new style trace event so this CL adds and updates
WebRTCs Perfetto configuration.
* Changes all #includes to target "third_party/perfetto". Added this
to DEPS.
* Expose the Perfetto public config in the "tracing" group using
an all_dependent_configs statement. This means the config is included
in all parts that include the "//:tracing" group. However, direct
perfetto includes are banned per DEPS.
* In order to expose Perfetto types (ie Flow/TerminatingFlow) the
perfetto headers are a dependancy on all targets. This should not
affect binary size as these are not used when perfetto is not enabled
and will not be linked.
Bug: b/42226290
Change-Id: I5711d81dae95ee907cbcd41bf1ee9b55d2ec595c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349161
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#42197}
This adds Perfetto support to WebRTC with a GN flag rtc_use_perfetto.
The configuration of perfetto depends on whether or not webrtc is
build within Chrome or not. When in Chrome, WebRTC will depend on
//third_party/perfetto:libperfetto. When building standalone, specific includes required for Perfetto are exposed with the library webrtc_libperfetto.
The perfetto trace API is exposed with a header export in
trace_event.h which is used instead of the legacy API.
The addition of Perfetto means there are 4 compilation modes for
tracing in WebRTC,
1. No tracing implementation.
2. Legacy tracing (AddTraceEvent/GetCategoryEnabled).
3.a. Perfetto statically linked (webrtc_libperfetto).
3.b. Perfetto in Chrome (Chrome's libperfetto).
This CL removes the tracing expectations from
rtc_stats_integrationtest.cc because those directly used the old API.
Integration into Chrome is a follow up CL which depends on
https://chromium-review.googlesource.com/c/chromium/src/+/5471691.
Tested: Ran Chrome with Perfetto and traces appear. WebRTC Unit test tracing working: https://ui.perfetto.dev/#!?s=04ea2613ea36b814394639a1ec4b60be5b5097527f1a485995ecc13469885468
Bug: webrtc:15917
Change-Id: I537d79dc247c2b759689910c621087286a4d8fdc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347880
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Evan Shrubsole <eshr@google.com>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
Cr-Commit-Position: refs/heads/main@{#42166}
This poison guards against accidental use of EnvironmentFactory and thus ensures low level WebRTC class would use utilities from propagated environment instead of accidentally using a default implementation.
This poison extends and thus replaces default task queue poison.
Bug: webrtc:15656
Change-Id: I577bef8af08b9c7dd649ad5a2284eb236e6f4a8f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/328380
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41247}
Reasons:
- the code is no longer used in Chrome
- it is conceptually weird for WebRTC to have JSON parsing in its API
- there are concerns around the reliability of the underlying JSON library
Additionally, this CL removes the rtc_json "poisonous" attribute: the scheme is incompatible and redundant with testonly.
Bug: webrtc:1493351
Change-Id: I0b621b0e3f183df7315919d9c89242fbe387928f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325062
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41014}
When built for chromium, some webrtc implementations are overridden and
are implemented by chrome's "//base". For instance webrtc::Location is
implemented by base::Location. So far so good, the affected targets are
correctly defined in GN to depend on base.
The problem: Most targets in webrtc do not declare correctly their
public_deps. When a public header of a target includes one from its
dependency, the dependency must be a public_deps. The public_deps
instruct GN to forward the capability to use code from the dependency
toward the dependent.
Unfortunately, it is not possible to fix the `public_deps` in webrtc,
because its is disallowed via a presubmit. See:
https://webrtc-review.googlesource.com/c/src/+/30262
WebRTC developers decided not to use `public_deps`, because GN config
are "translated" toward different kind of downstream build system who do
not really support the `public` dependencies concept. Instead WebRTC is
using some "common" configuration applied to all of its targets.
This patch add `rtc_common_public_deps` argument, to let embedders
add the dependencies WebRTC depends on.
Bug: chromium:1467773
Change-Id: I7de43372414a09886fcb07905451e6339c8ecc64
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/316660
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40595}
This is part of effort to enable HEVC for WebRTC. Parser added here to support parsing of QP/picture size for bitstream, for dynamic adaptation and stream metadata abstraction.
Bug: webrtc:13485
Change-Id: I2fbdf210e72e77989ca87ce285da174df5bedd5c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298421
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40572}
WebRTC unconditionally enables ARC for Objective-C code. Chromium is
now enabling this globally, so change WebRTC to only enable it if it's
not already enabled.
Bug: chromium:733237
Change-Id: I0d5694d0640bb79ae83209aa0bdd36e099b85042
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/314180
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40493}
This CL also adds the prefix RTC_TESTING to `ios_internal_pure_release_bot_arm64` in order to avoid ODR
violations.
Bug: b/292472934
Change-Id: If63020e679c8670b4c797217eb38fc8c2954d422
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313240
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40476}
Add a WebRTC-specific arg that can be used to control use of targets
that rely on //third_party/google_benchmarks, so the .gni in that
directory can eventually be removed.
Bug: chromium:1404759
Change-Id: I2a9422fae119ca13eb50028d962fc0a671b5fb33
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297460
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39553}
Until now you only had the option to RTC_DCHECK for unregistered field
trials. This makes it possible to log a warning instead.
Bug: webrtc:14154
Change-Id: I8628054e3c9b5d690f241a93e61299126b732ed0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295300
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39417}
For now, the run-time check will only be enabled if the
rtc_strict_field_trials GN arg is set.
In order to allow testing with imaginary field trial keys, two test
helpers have been added. It's a bit awkward to test these since the
field trial string is already global, hence the helpers are also
modifying global state. Tests must make sure this global state is reset
between runs. Things won't be an issue anymore when [1] has removed the
global string.
[1] https://crbug.com/webrtc/10335
Bug: webrtc:14154
Change-Id: Ida44cc817079d7177325e2228cf1f1d242b799e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276269
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38447}
Replace `is_chromecast` with `is_castos` and `is_cast_android` as
appropriate. See linked bug for further context.
Bug: chromium:1219802
Change-Id: If24af59e058940b7259cf4f1d9a3ba2ee0449cdb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265601
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: David Dorwin <ddorwin@google.com>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Ryan Keane <rwkeane@google.com>
Cr-Commit-Position: refs/heads/main@{#37230}
(Used to run gtests on iOS, but we don't want to depend on //base.)
Optimistically try to use the existing partial fork
Bug: webrtc:13402
Change-Id: I10528670862f2db67e77adb73b8a71b19642666d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260328
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36703}
The two GN templates are nearly identical, so merge them to reduce
maintenance.
Bug: webrtc:13949
Change-Id: I5f53ade5f9d09ce6f23a6cb29c9d39df4485a237
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258380
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#36495}
Create a server using:
./data_channel_benchmark --server --port 12345
Start the flow of data from the server to a client using:
./data_channel_benchmark --port 12345 --transfer_size 100
The throughput is reported on the server console.
The negotiation does not require a 3rd party server and is done over a
gRPC transport. No TURN server is configured, so both peers need to be
reachable using STUN only.
Bug: webrtc:13288
Change-Id: Iac9a96cf390ab465ea45a46bf0b40950c56dfceb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235661
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36206}
It seems the build failure is fixed and it is required so that "testRunGoogleTests" would be invoked as a "xctest".
Bug: b/223364112
Change-Id: I2572af62d14c71e31b751c73a76e9f6e5d064ea8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/254682
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#36202}
The flags isolated-script-test-output and isolated-script-test-perf-output need to be consumed by the tests.
The generated .app folder in added in the data list of the gni file.
This will make it available in the runtime_deps file and thus will be populated to the swarming tasks.
Bug: webrtc:13556
Change-Id: I2c75774b847d9f686c3abc00ba0400bbc3fcefae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/240520
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Christoffer Jansson <jansson@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#36029}
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}
This is a reland of f2177f6612
Original change's description:
> PipeWire capturer: implement proper DMA-BUFs support
>
> Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> use DMA-BUFs by default, but only when client asks specifically for
> them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> While current implementation works just fine on integrated graphics
> cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> code either crashes or screensharing is slow and unusable.
>
> To fix this, DMA-BUFs has to be opened using OpenGL context and not
> being directly mmaped(). This implementation requires to use DMA-BUF
> modifiers, as they are now mandatory for DMA-BUFs usage.
>
> Documentation for this behavior can be found here:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
>
> Bug: chromium:1233417
> Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34889}
Bug: chromium:1233417
Change-Id: I308501d86ec18ab6df9bcee569c4b72df7926549
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231180
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35152}
Ozone is default now in Chromium and non-Ozone/X11 (aka use_x11) is
deprecated. During the transition period use_x11 == ozone_platform_x11.
Bug: chromium:1096425
Change-Id: Ie3643360ec6607796533054bdedf8e2bb8e7e749
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231650
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35040}
This reverts commit 677195d3eb.
Reason for revert: Broke WebRTC to Chrome rolls:
https://crrev.com/c/3141000
example: https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/790256/overview
The error is similar to the failure on previous attempt to land this CL. See: https://crrev.com/c/3135220, and crash https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/787945/overview
Original change's description:
> Reland "PipeWire capturer: implement proper DMA-BUFs support""
>
> This is a reland of f2177f6612
>
> Original change's description:
> > PipeWire capturer: implement proper DMA-BUFs support
> >
> > Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> > use DMA-BUFs by default, but only when client asks specifically for
> > them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> > While current implementation works just fine on integrated graphics
> > cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> > code either crashes or screensharing is slow and unusable.
> >
> > To fix this, DMA-BUFs has to be opened using OpenGL context and not
> > being directly mmaped(). This implementation requires to use DMA-BUF
> > modifiers, as they are now mandatory for DMA-BUFs usage.
> >
> > Documentation for this behavior can be found here:
> > https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
> >
> > Bug: chromium:1233417, webrtc:13137
> > Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Reviewed-by: Tommi <tommi@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#34889}
>
> Bug: chromium:1233417, webrtc:13137
> Change-Id: I7d5763dd5db708cee20a31e559b26db0287f40d6
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230946
> Reviewed-by: Tommi <tommi@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34903}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1233417, webrtc:13137
Change-Id: I64e2ce864f69e6097aba65ade04af7166e407409
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231135
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34915}
This is a reland of f2177f6612
Original change's description:
> PipeWire capturer: implement proper DMA-BUFs support
>
> Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> use DMA-BUFs by default, but only when client asks specifically for
> them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> While current implementation works just fine on integrated graphics
> cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> code either crashes or screensharing is slow and unusable.
>
> To fix this, DMA-BUFs has to be opened using OpenGL context and not
> being directly mmaped(). This implementation requires to use DMA-BUF
> modifiers, as they are now mandatory for DMA-BUFs usage.
>
> Documentation for this behavior can be found here:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
>
> Bug: chromium:1233417, webrtc:13137
> Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34889}
Bug: chromium:1233417, webrtc:13137
Change-Id: I7d5763dd5db708cee20a31e559b26db0287f40d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230946
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34903}
This reverts commit f2177f6612.
Reason for revert: Broke WebRTC to Chrome rolls:
https://chromium-review.googlesource.com/c/chromium/src/+/3135220
example: https://ci.chromium.org/ui/p/chromium/builders/try/fuchsia-x64-cast/431230/overview
ERROR at //third_party/webrtc/modules/desktop_capture/linux/egl_dmabuf.cc:26:11: Include not allowed.
#include "rtc_base/sanitizer.h"
^-------------------
It is not in any dependency of
//third_party/webrtc/modules/desktop_capture:desktop_capture_generic
The include file is in the target(s):
//third_party/webrtc/rtc_base:sanitizer
which should somehow be reachable.
Original change's description:
> PipeWire capturer: implement proper DMA-BUFs support
>
> Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> use DMA-BUFs by default, but only when client asks specifically for
> them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> While current implementation works just fine on integrated graphics
> cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> code either crashes or screensharing is slow and unusable.
>
> To fix this, DMA-BUFs has to be opened using OpenGL context and not
> being directly mmaped(). This implementation requires to use DMA-BUF
> modifiers, as they are now mandatory for DMA-BUFs usage.
>
> Documentation for this behavior can be found here:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
>
> Bug: chromium:1233417, webrtc:13137
> Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34889}
TBR=mbonadei@webrtc.org,tommi@webrtc.org,sprang@webrtc.org,mfoltz@chromium.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com,grulja@gmail.com
Change-Id: I2c573f17adbb216156cd72f62f4dbb7328f8fb6a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1233417, webrtc:13137
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230944
Reviewed-by: Olga Sharonova <olka@webrtc.org>
Commit-Queue: Olga Sharonova <olka@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34892}
Currently both KWin (KDE) and Mutter (GNOME) window managers don't
use DMA-BUFs by default, but only when client asks specifically for
them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
While current implementation works just fine on integrated graphics
cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
code either crashes or screensharing is slow and unusable.
To fix this, DMA-BUFs has to be opened using OpenGL context and not
being directly mmaped(). This implementation requires to use DMA-BUF
modifiers, as they are now mandatory for DMA-BUFs usage.
Documentation for this behavior can be found here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
Bug: chromium:1233417, webrtc:13137
Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34889}
