This CL allows the users to propose custom resolution to server
for the captured pipewire streams.
Bug: chromium:1291247
Change-Id: Iaae2c73df1a5f5ebac651ce7d087af4c273113c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263360
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36979}
getDisplayMedia capture the view of the screens and windows
in the capture dialog, but the issue is that captured view
of the Youtube somehow is blank. It repros only in certain
circumstances, for example, Canary channel.
If user reinstall the Canary as fresh new, we observed that
it doesn't repro.
Cause:
We aren't sure what's cause of this one yet.
Solution:
We decided to provide fallback WGC capturer when the main
capturer (GDI) shows blank. WGC could show yellow outline
in prior Win11 OS, but yellow outline looks better than
blank.
The blank detector and fallback capturer are what screen capturer
already supported. So, the solution will follow similar
pattern in the window capturer.
Bug: webrtc:13726
Change-Id: I620c817d259d7bb5c295adab11c4444349ab1c6c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/252625
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36224}
Make PipeWire stream shared through DesktopCaptureOptions (similar to
X11 implementation sharing XDisplay) so we can implement better cursor
support with our own MouseCursorMonitor implementation.
Bug: webrtc:13429
Change-Id: I781482aa29cee0c105c42e5109f28e95dde9881b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238174
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35765}
This reverts commit 3a285224b6.
Reason for revert: Still breaking downstream projects due to not using forward headers. I will talk to Mark separately about the usage.
Original change's description:
> Reland "Linux capturers: organize X11 and Wayland implementations into separate folders"
>
> Bug: webrtc:13429
> Change-Id: I6e88de4f7ebcb64076312d83ac2c79db24f85ad8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239841
> Commit-Queue: Mark Foltz <mfoltz@chromium.org>
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#35481}
TBR=grulja@gmail.com,mfoltz@chromium.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I1f75e3d89495f2a9a31d0f4406a3efdf0d95f74a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:13429
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/240064
Owners-Override: Christoffer Jansson <jansson@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Christoffer Jansson <jansson@google.com>
Cr-Commit-Position: refs/heads/main@{#35484}
This reverts commit 998e9bd5c5.
Reason for revert: Breaks downstream projects because some headers
have been renamed without providing a forward header for backwards
compatibility.
Original change's description:
> Linux capturers: organize X11 and Wayland implementations into separate folders
>
> Bug: webrtc:13429
> Change-Id: I2db727797c2ca2bd85937ff732ce3f68bb45469a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238173
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Mark Foltz <mfoltz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#35471}
TBR=tommi@webrtc.org,sprang@chromium.org,mfoltz@chromium.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com,grulja@gmail.com
Change-Id: I2aadfeb30151fcbe1a8c05e856be989d60bb10a3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:13429
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239821
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#35472}
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}
Enumerating windows owned by the current process on Windows has some
complications due to the GetWindowText*() APIs potentially causing a
deadlock. The APIs will send messages to the window's message loop, and
if the message loop is waiting on this operation we will enter a
deadlock.
I previously put in a mitigation for this [1] which brought the
incidence rate down by an order of magnitude, but we are still seeing
this issue fairly frequently.
So, I've added DesktopCaptureOption enumerate_current_process_windows
which allows consumers to avoid this issue completely by ignoring
these potentially problematic windows.
By default the flag is set to true which equates with the current
behavior, consumers can set the flag to false to get the new behavior.
I've also updated all the capturers that enumerate windows on Windows
to respect the option.
[1] https://webrtc-review.googlesource.com/c/src/+/195365
Bug: chromium:1152841
Change-Id: I0e0d868957d6fbe1e607a440b3a909d005c93ccf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219380
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#34191}
This changes add two new options to the DesktopCaptureOptions class so
consumers can opt in to using the WGC capturer. The capturer is still
behind the RTC_ENABLE_WIN_WGC build flag which is off by default, so
these options will have no affect until that flag is enabled.
Bug: webrtc:11760
Change-Id: Ib7166f3bb335f29aeff8cb5d2bebea2c06c14d4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215243
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33837}
This reverts commit 84524e6b19.
Reason for revert: https://webrtc-review.googlesource.com/c/src/+/160649/33#message-a83e8959e03a274642ca2ce1abb9ea0099f08097 + suspected in breaking WebRTC to Chromium rolls https://chromium-review.googlesource.com/c/chromium/src/+/2468139
Original change's description:
> Improve screen sharing with PipeWire on Wayland
>
> Currently, sharing a screen or a window on Wayland opens unnecessary
> preview dialog on Chromium side, which is then followed by a similar
> dialog on xdg-desktop-portal side. The Chromium dialog is useless on
> Wayland, as it doesn't show anything. This is because Chromium doesn't
> have access to screen content as in case of X11 session. To fix this, we
> want to avoid showing the preview dialog in case we find that we run on
> Wayland and only pick a screen or a window from the dialog that comes
> from xdg-desktop-portal.
>
> This patch splits BaseCapturerPipeWire class, moving portal related code
> into XdgPortalBase, which does all the DBus communication and which is
> supposed to be reused by BaseCapturerPipeWire when the user confirms
> the dialog from xdg-desktop-portal. The XdgPortalBase is extended to
> support multiple calls at once, where each call is identified by Id.
>
> Relevant change on Chromium side will be in a different review.
>
> Bug: chromium:682122
> Change-Id: I2bcd07d16a5eb3b902db63ea9a164c5bd39c23a0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187492
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32388}
TBR=mbonadei@webrtc.org,tommi@webrtc.org,sprang@webrtc.org,guidou@webrtc.org,mfoltz@chromium.org,grulja@gmail.com
Change-Id: I1a9748ced5626903b12214d677c7b8919c2ac385
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:682122
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188380
Reviewed-by: Olga Sharonova <olka@webrtc.org>
Commit-Queue: Olga Sharonova <olka@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32398}
Currently, sharing a screen or a window on Wayland opens unnecessary
preview dialog on Chromium side, which is then followed by a similar
dialog on xdg-desktop-portal side. The Chromium dialog is useless on
Wayland, as it doesn't show anything. This is because Chromium doesn't
have access to screen content as in case of X11 session. To fix this, we
want to avoid showing the preview dialog in case we find that we run on
Wayland and only pick a screen or a window from the dialog that comes
from xdg-desktop-portal.
This patch splits BaseCapturerPipeWire class, moving portal related code
into XdgPortalBase, which does all the DBus communication and which is
supposed to be reused by BaseCapturerPipeWire when the user confirms
the dialog from xdg-desktop-portal. The XdgPortalBase is extended to
support multiple calls at once, where each call is identified by Id.
Relevant change on Chromium side will be in a different review.
Bug: chromium:682122
Change-Id: I2bcd07d16a5eb3b902db63ea9a164c5bd39c23a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187492
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32388}
This reverts commit 9b87037073.
Reason for revert: Causing compile failures that prevent rolling into chrome.
See https://ci.chromium.org/p/chromium/builders/try/cast_shell_linux/726007https://chromium-review.googlesource.com/c/chromium/src/+/2461647
Original change's description:
> Improve screen sharing with PipeWire on Wayland
>
> Currently, sharing a screen or a window on Wayland opens unnecessary
> preview dialog on Chromium side, which is then followed by a similar
> dialog on xdg-desktop-portal side. The Chromium dialog is useless on
> Wayland, as it doesn't show anything. This is because Chromium doesn't
> have access to screen content as in case of X11 session. To fix this, we
> want to avoid showing the preview dialog in case we find that we run on
> Wayland and only pick a screen or a window from the dialog that comes
> from xdg-desktop-portal.
>
> This patch splits BaseCapturerPipeWire class, moving portal related code
> into XdgPortalBase, which does all the DBus communication and which is
> supposed to be reused by BaseCapturerPipeWire when the user confirms
> the dialog from xdg-desktop-portal. The XdgPortalBase is extended to
> support multiple calls at once, where each call is identified by Id.
>
> Relevant change on Chromium side will be in a different review.
>
> Bug: chromium:682122
> Change-Id: If8afd36da66231eb154cdc00114908ac897ee4cf
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160649
> 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/master@{#32342}
TBR=mbonadei@webrtc.org,jamiewalch@chromium.org,tommi@webrtc.org,sprang@webrtc.org,tomas.popela@gmail.com,grulja@gmail.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:682122
Change-Id: I41518f795e34b84374bc8208b711cfeb0a070578
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187352
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32365}
Currently, sharing a screen or a window on Wayland opens unnecessary
preview dialog on Chromium side, which is then followed by a similar
dialog on xdg-desktop-portal side. The Chromium dialog is useless on
Wayland, as it doesn't show anything. This is because Chromium doesn't
have access to screen content as in case of X11 session. To fix this, we
want to avoid showing the preview dialog in case we find that we run on
Wayland and only pick a screen or a window from the dialog that comes
from xdg-desktop-portal.
This patch splits BaseCapturerPipeWire class, moving portal related code
into XdgPortalBase, which does all the DBus communication and which is
supposed to be reused by BaseCapturerPipeWire when the user confirms
the dialog from xdg-desktop-portal. The XdgPortalBase is extended to
support multiple calls at once, where each call is identified by Id.
Relevant change on Chromium side will be in a different review.
Bug: chromium:682122
Change-Id: If8afd36da66231eb154cdc00114908ac897ee4cf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160649
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/master@{#32342}
USE_X11 is magically set by the toolchain. Let's tie this to
whether X11 extensions is on or not. WEBRTC_USE_X11 is used
in the audio device module so let's be consistent with that.
Bug: b/143587130
Change-Id: I15b1744c9acb534dbdf2119deb2dc5d17aa04184
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161901
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30080}
* Introduce a FullScreenWindowDetector to manage routines for updating the list of sources being application agnostic, inspired by FullScreenChromeWindowDetector.
* Introduce a FullScreenApplicationHandler to make a decision about changing window to share in application specific way, inspired by FullScreenChromeWindowDetector.
* Remove FullScreenChromeWindowDetector as redundant.
* Add FullScreenApplicationHandler for MS PowerPoint and Apple Keynote on MacOS.
* Add FullScreenApplicationHandler for MS PowerPoint on Windows.
Bug: webrtc:3852
Change-Id: I06507d929308e85b882b2f8210a025afef7f26a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156020
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Justin Uberti <juberti@webrtc.org>
Reviewed-by: Wez <wez@google.com>
Cr-Commit-Position: refs/heads/master@{#29993}
Currently, apps using WebRTC for window capture only get the benefits of
using CroppingWindowCapturer on Windows (described below) after changing
calls to DesktopCapturer::CreateWindowCapturer to instead call
CroppingWindowCapturer::CreateCapturer. This change adds a new flag to
DesktopCaptureOptions to allow opting in to the faster capture-screen-
and-crop path via the older & more discoverable API.
Benefits of using CroppingWindowCapturer's capture-screen-and-crop path
when possible:
1) It's significantly faster, up to ~36ms/frame (~160x) faster than the
capture-window-contents path in my testing (more details are in the
bug). This difference increased with the recent fix for
https://crbug.com/webrtc/10734 .
2) It allows capture of menus & tooltips (plus dialogs if
https://crbug.com/webrtc/10767 is fixed), partially mitigating
https://crbug.com/980864 .
Downsides of using it:
1) It may inadvertently capture occluding windows that aren't detected
properly, e.g. some system UI: https://crbug.com/webrtc/10835 .
2) It may capture some neighboring regions when moving/resizing the
captured window.
The new flag is not enabled by default, so the default behavior is
unchanged. This could perhaps be revisited after addressing
https://crbug.com/webrtc/10835 .
Bug: webrtc:10825
Change-Id: Ib77e5facc7240c5df311fe1fe204d0d8ea22a96a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146823
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28695}
The type rtc::scoped_refptr<T> is now part of api/. Please include it from
api/scoped_refptr.h.
More info: See: https://groups.google.com/forum/#!topic/discuss-webrtc/Mme2MSz4z4o.
Bug: webrtc:9887, webrtc:8205
No-Try: True
Change-Id: Ic6c7c81e226e59f12f7933e472f573ae097b55bf
Reviewed-on: https://webrtc-review.googlesource.com/c/119041
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26414}
This is a follow-up to
https://webrtc-review.googlesource.com/c/src/+/106280.
This time the whole code base is covered.
Some files may have not been fixed though, whenever the IWYU tool
was breaking the build.
Bug: webrtc:8311
Change-Id: I2c31f552a87e887d33931d46e87b6208b1e483ef
Reviewed-on: https://webrtc-review.googlesource.com/c/111965
Commit-Queue: Yves Gerey <yvesg@google.com>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25830}
The content_unittests failure was caused by wrong path in the cfi
blacklist (when the files from x11 folder were moved to the linux
folder by this change).
Bug: chromium:682122
Change-Id: I4f7f6c5a73a981feeac18494749f85935e812981
Reviewed-on: https://webrtc-review.googlesource.com/c/110461
Commit-Queue: Tomáš Popela <tomas.popela@gmail.com>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25621}
This reverts commit dd20c9c1e3.
Reason for revert: Speculative revert; looks like it causes crashes on official builders. See crbug.com/901319.
Original change's description:
> Add support for screen sharing with PipeWire on Wayland
>
> Currently, when users want to use the screen sharing and are using the
> Wayland display server (the default on Fedora distribution), then it
> doesn't work, because the WebRTC only includes the X11 implementation.
> This change adds the support by using the PipeWire multimedia server.
>
> The PipeWire implementation in WebRTC stays in
> screen-capturer-pipewire.c and is guarded by the rtc_use_pipewire build
> flag that is automatically enabled on Linux.
>
> More information are included in the relevant commit messages.
>
> Tested on the current Chromium master and Firefox.
>
> The sysroot changes are requested in:
> https://chromium-review.googlesource.com/c/chromium/src/+/1258174
>
> Co-authored-by: Jan Grulich <grulja@gmail.com>
> Co-authored-by: Eike Rathke <erathke@redhat.com>
> Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
>
> BUG=chromium:682122
>
> Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
> Reviewed-on: https://webrtc-review.googlesource.com/c/103504
> Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
> Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
> Reviewed-by: Brave Yao <braveyao@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#25461}
TBR=phoglund@webrtc.org,jamiewalch@chromium.org,niklas.enbom@webrtc.org,braveyao@webrtc.org,tomas.popela@gmail.com
# Not skipping CQ checks because original CL landed > 1 day ago.
NOPRESUBMIT=true
Bug: chromium:682122, chromium:901319
Change-Id: I4ca5da77daea73cae1232953a0d633900a85a93d
Reviewed-on: https://webrtc-review.googlesource.com/c/109584
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25522}
Currently, when users want to use the screen sharing and are using the
Wayland display server (the default on Fedora distribution), then it
doesn't work, because the WebRTC only includes the X11 implementation.
This change adds the support by using the PipeWire multimedia server.
The PipeWire implementation in WebRTC stays in
screen-capturer-pipewire.c and is guarded by the rtc_use_pipewire build
flag that is automatically enabled on Linux.
More information are included in the relevant commit messages.
Tested on the current Chromium master and Firefox.
The sysroot changes are requested in:
https://chromium-review.googlesource.com/c/chromium/src/+/1258174
Co-authored-by: Jan Grulich <grulja@gmail.com>
Co-authored-by: Eike Rathke <erathke@redhat.com>
Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
BUG=chromium:682122
Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
Reviewed-on: https://webrtc-review.googlesource.com/c/103504
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25461}
This reverts commit 9e24dcff16.
Reason for revert: Breaks chromium.webrtc.fyi bots.
Original change's description:
> Export symbols needed by the Chromium component build (part 1).
>
> This CL uses RTC_EXPORT (defined in rtc_base/system/rtc_export.h)
> to mark WebRTC symbols as visible from a shared library, this doesn't
> mean these symbols are part of the public API (please continue to refer
> to [1] for info about what is considered public WebRTC API).
>
> [1] - https://webrtc.googlesource.com/src/+/HEAD/native-api.md
>
> Bug: webrtc:9419
> Change-Id: I802abd32874d42d3aa5ecd3c8022e7cf5e043d99
> Reviewed-on: https://webrtc-review.googlesource.com/c/103505
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#24969}
TBR=mbonadei@webrtc.org,kwiberg@webrtc.org,nisse@webrtc.org
Change-Id: I01f6e18f0d2c0f0309cdaa6c943c3927e1f1f49f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9419
Reviewed-on: https://webrtc-review.googlesource.com/c/103720
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24974}
This CL uses RTC_EXPORT (defined in rtc_base/system/rtc_export.h)
to mark WebRTC symbols as visible from a shared library, this doesn't
mean these symbols are part of the public API (please continue to refer
to [1] for info about what is considered public WebRTC API).
[1] - https://webrtc.googlesource.com/src/+/HEAD/native-api.md
Bug: webrtc:9419
Change-Id: I802abd32874d42d3aa5ecd3c8022e7cf5e043d99
Reviewed-on: https://webrtc-review.googlesource.com/c/103505
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24969}
Running clang-format with chromium's style guide.
The goal is n-fold:
* providing consistency and readability (that's what code guidelines are for)
* preventing noise with presubmit checks and git cl format
* building on the previous point: making it easier to automatically fix format issues
* you name it
Please consider using git-hyper-blame to ignore this commit.
Bug: webrtc:9340
Change-Id: I694567c4cdf8cee2860958cfe82bfaf25848bb87
Reviewed-on: https://webrtc-review.googlesource.com/81185
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23660}
The given IOSurfaceRef was ignored until now. Wrap it into the new
DesktopFrameIOSurface. The new DesktopFrameProvider object is there
to manage them as it has to be done per display id.
From initial measurement this speed-up the frame capture by 2.
Disabled by default for now but it can be enabled by calling
options.set_use_iosurface. This CL will allow to do some advanced
tests.
Bug: webrtc:8652
Change-Id: Ia9ac0b69b30098774941cb378804b45cb1710119
Reviewed-on: https://webrtc-review.googlesource.com/33014
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#22801}
In https://webrtc-review.googlesource.com/c/src/+/1560 we moved WebRTC
from src/webrtc to src/ (in order to preserve an healthy git history).
This CL takes care of fixing header guards, #include paths, etc...
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=tommi@webrtc.org
Bug: chromium:611808
Change-Id: Iea91618212bee0af16aa3f05071eab8f93706578
Reviewed-on: https://webrtc-review.googlesource.com/1561
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19846}
In order to eliminate the WebRTC Subtree mirror in Chromium,
WebRTC is moving the content of the src/webrtc directory up
to the src/ directory.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=tommi@webrtc.org
Bug: chromium:611808
Change-Id: Iac59c5b51b950f174119565bac87955a7994bc38
Reviewed-on: https://webrtc-review.googlesource.com/1560
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19845}
2017-09-15 04:25:06 +00:00
Renamed from webrtc/modules/desktop_capture/desktop_capture_options.h (Browse further)
