This CL completes the removal of assert() and relative headers from
the codebase (excluded
//examples/objc/AppRTCMobile/third_party/SocketRocket which is in a
third_party sub-directory).
Bug: webrtc:6779
Change-Id: I93ed57168d2c0e011626873d66529488c5f484f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225546
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34528}
CL partially auto-generated with:
git grep -l "\bassert(" | grep "\.[c|h]" | \
xargs sed -i 's/\bassert(/RTC_DCHECK(/g'
And with:
git grep -l "RTC_DCHECK(false)" | \
xargs sed -i 's/RTC_DCHECK(false)/RTC_NOTREACHED()/g'
With some manual changes to include "rtc_base/checks.h" where
needed.
A follow-up CL will remove assert() from Obj-C code as well
and remove the #include of <assert.h>.
The choice to replace with RTC_DCHECK is because assert()
is because RTC_DCHECK has similar behavior as assert()
based on NDEBUG.
This CL also contains manual changes to switch from
basic RTC_DCHECK to other (preferred) versions like
RTC_DCHECK_GT (and similar).
Bug: webrtc:6779
Change-Id: I00bed8886e03d685a2f42324e34aef2c9b7a63b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224846
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34442}
This seems an issue with recently updated MSan prebuilt libraries,
or at least the issue started to happen after that. While investigating
let's skip the two tests to unblock presubmit and LKGR.
Bug: webrtc:12950
Change-Id: Iebd391deb9f669f6471bd41aae1ab32b7f6f8fc5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225420
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34434}
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}
We need to specify that the cursor should be included in the stream as
by default xdg-desktop-portal defaults to hidden cursor.
Bug: chromium:1202526
Change-Id: Ic4742da2e51f7ed28cb9d7b6b0c069c1fa7d0cee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214782
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34137}
This reverts commit 793bac569fdf1be16cbf24d7871d20d00bbec81b.
Reason for revert: rare compilation error fixed
Original change's description:
> Revert "Refactor the PlatformThread API."
>
> This reverts commit c89fdd716c4c8af608017c76f75bf27e4c3d602e.
>
> Reason for revert: Causes rare compilation error on win-libfuzzer-asan trybot.
> See https://ci.chromium.org/p/chromium/builders/try/win-libfuzzer-asan-rel/713745?
>
> Original change's description:
> > Refactor the PlatformThread API.
> >
> > PlatformThread's API is using old style function pointers, causes
> > casting, is unintuitive and forces artificial call sequences, and
> > is additionally possible to misuse in release mode.
> >
> > Fix this by an API face lift:
> > 1. The class is turned into a handle, which can be empty.
> > 2. The only way of getting a non-empty PlatformThread is by calling
> > SpawnJoinable or SpawnDetached, clearly conveying the semantics to the
> > code reader.
> > 3. Handles can be Finalized, which works differently for joinable and
> > detached threads:
> > a) Handles for detached threads are simply closed where applicable.
> > b) Joinable threads are joined before handles are closed.
> > 4. The destructor finalizes handles. No explicit call is needed.
> >
> > Fixed: webrtc:12727
> > Change-Id: Id00a0464edf4fc9e552b6a1fbb5d2e1280e88811
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215075
> > Commit-Queue: Markus Handell <handellm@webrtc.org>
> > Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> > Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> > Reviewed-by: Tommi <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33923}
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> TBR=handellm@webrtc.org
>
> Bug: webrtc:12727
> Change-Id: Ic0146be8866f6dd3ad9c364fb8646650b8e07419
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217583
> Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
> Reviewed-by: Markus Handell <handellm@webrtc.org>
> Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33936}
# Not skipping CQ checks because this is a reland.
Bug: webrtc:12727
Change-Id: Ifd6f44eac72fed84474277a1be03eb84d2f4376e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217881
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33950}
This reverts commit c89fdd716c4c8af608017c76f75bf27e4c3d602e.
Reason for revert: Causes rare compilation error on win-libfuzzer-asan trybot.
See https://ci.chromium.org/p/chromium/builders/try/win-libfuzzer-asan-rel/713745?
Original change's description:
> Refactor the PlatformThread API.
>
> PlatformThread's API is using old style function pointers, causes
> casting, is unintuitive and forces artificial call sequences, and
> is additionally possible to misuse in release mode.
>
> Fix this by an API face lift:
> 1. The class is turned into a handle, which can be empty.
> 2. The only way of getting a non-empty PlatformThread is by calling
> SpawnJoinable or SpawnDetached, clearly conveying the semantics to the
> code reader.
> 3. Handles can be Finalized, which works differently for joinable and
> detached threads:
> a) Handles for detached threads are simply closed where applicable.
> b) Joinable threads are joined before handles are closed.
> 4. The destructor finalizes handles. No explicit call is needed.
>
> Fixed: webrtc:12727
> Change-Id: Id00a0464edf4fc9e552b6a1fbb5d2e1280e88811
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215075
> Commit-Queue: Markus Handell <handellm@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33923}
# Not skipping CQ checks because original CL landed > 1 day ago.
TBR=handellm@webrtc.org
Bug: webrtc:12727
Change-Id: Ic0146be8866f6dd3ad9c364fb8646650b8e07419
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217583
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33936}
PlatformThread's API is using old style function pointers, causes
casting, is unintuitive and forces artificial call sequences, and
is additionally possible to misuse in release mode.
Fix this by an API face lift:
1. The class is turned into a handle, which can be empty.
2. The only way of getting a non-empty PlatformThread is by calling
SpawnJoinable or SpawnDetached, clearly conveying the semantics to the
code reader.
3. Handles can be Finalized, which works differently for joinable and
detached threads:
a) Handles for detached threads are simply closed where applicable.
b) Joinable threads are joined before handles are closed.
4. The destructor finalizes handles. No explicit call is needed.
Fixed: webrtc:12727
Change-Id: Id00a0464edf4fc9e552b6a1fbb5d2e1280e88811
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215075
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33923}
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 change disables native cursor capture in WgcCapturerWin to better
support the existing idiom of wrapping a capturer in a
DesktopAndCursorComposer. That means we also need to set the top_left
property of output DesktopFrames, so I've also implemented GetTopLeft in
WgcCaptureSource to facilitate this. I've also added a few unit tests
for WgcCaptureSource.
Bug: webrtc:12654
Change-Id: I5c9988a6f8548b584451b073ac29fbb482e09e2e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215102
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33821}
Previously, windows captured by WgcCapturerWin may have been occluded
by other windows with no functionality to bring them to the top of the
z order. This change implements FocusOnSelectedSource for
WgcCapturerWin to afford consumers this functionality, and match the
experience offered by current capturers.
Bug: webrtc:12664
Change-Id: I8bc067ade90fba0be66a9be57d3429ba54ba1ae0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215241
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33809}
On a 32bit system, this reduces the allocation size of the flag
down from 12 bytes to 8, and removes the need for a vtable (the extra
4 bytes are the vtable pointer).
The downside is that this change makes the binary layout of the
flag, less compatible with RefCountedObject<> based reference counting
objects and thus we don't immediately get the benefits of identical
COMDAT folding and subsequently there's a slight binary size increase.
With wider use, the binary size benefits will come.
Bug: none
Change-Id: I04129771790a3258d6accaf0ab1258b7a798a55e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215681
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33793}
This CL adds a new property to the DesktopFrame interface to indicate
that the capturer supports cursor capture and the frame may contain
an image of the cursor (if the cursor was over the window or screen
being captured). This allows the DesktopAndCursorComposer to avoid
compositing another image of the cursor on the frame.
This is preferred because natively capturing the cursor will likely
be more efficient, and for WGC the API to disable cursor capture
is only availabe on later versions of Win10, reducing the number
of users that could use it.
Bug: webrtc:12654
Change-Id: I992804ff2a65eb423fb8ecc66e066408dc05e849
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215341
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33780}
This changes modifies EnumerateCapturableWindows to accept an optional
parameter consisting of extended window styles that will prevent windows
with the specified styles from being returned. This allows us to filter
out windows with the WS_EX_TOOLWINDOW style for the WgcCapturerWin,
which does not support capture of such windows.
Bug: webrtc:12679
Change-Id: Id9ac28afd331ba20fcb7f9e7be54ea5eee2e022e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215161
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33779}
As part of adding the new WgcCapturerWin implementation of the
DesktopCapturer interface, we should ensure that we can measure the
health and success of this new code. In order to quantify that, I've
added telemetry to measure the usage of each capturer implementation,
the time taken to capture a frame, and any errors that are encountered
in the new implementation.
I've also set the capturer id property of frames so that we can measure
error rates and performance of each implementation in Chromium as well.
This CL must be completed after this Chromium CL lands:
2806094: Add histograms to record new WebRTC DesktopCapturer telemetry | https://chromium-review.googlesource.com/c/chromium/src/+/2806094
Bug: webrtc:9273
Change-Id: I33b0a008568a4df4f95e705271badc3313872f17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214060
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33716}
To maintain interoperability between different capturer implementations
this change updates WgcScreenSourceEnumerator to return a list of
device indices instead of a list of HMONITORs, and WgcScreenSource to
accept a device index as the input SourceId. WGC still requires an
HMONITOR to create the capture item, so this change also adds a utility
function GetHmonitorFromDeviceIndex to convert them, as well as new
tests to cover these changes.
Bug: webrtc:12663
Change-Id: Ic29faa0f023ebc26b4276cf29ef3d15d976e8615
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214600
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33673}
This CL fixes a buffer copying issue introduced in this CL:
https://webrtc-review.googlesource.com/c/src/+/196485
In the BasicDesktopFrame::CopyOf function, the src and dst params
were swapped. For me this manifested as a missing cursor when using
Chrome Remote Desktop. I don't know of any other bugs this caused
but I have to assume it affects all callers of the function given
that the copy will never occur.
Bug: chromium:1197210
Change-Id: I076bffbad1d658b1c6f4b0dffea17d339c867bef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214840
Commit-Queue: Joe Downing <joedow@google.com>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33672}
It was recommened to me to move this define to the top level BUILD.gn
file to avoid potential issues with the define not being available
where we need it.
Bug: webrtc:9273
Change-Id: Id0e939a51d1e381f684a3ae970569a255f52a5bb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214101
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33661}
WgcCaptureSession would crash when copying the frame data for an image
from a portrait oriented monitor. This is because we were using the
height of the image multiplied by the rowpitch of the buffer to
determine the size of the data to be copied. However, in portrait
mode the height measures the same dimension as the rowpitch, leading
to us overrunning the frame buffer.
The fix is to use the height and width of the image multiplied by
the number of bytes per pixel to determine how much data to copy
out of the buffer, and only use the rowpitch to advance the pointer
in the source data buffer. This has the added benefit of giving us
contiguous data, reducing the size of the DesktopFrame that we output.
Bug: webrtc:12490
Change-Id: I4c26f8864cb57ac566a742af70fea1da504b9706
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209501
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33532}
According to our previous data from trace_event with using direct memcpy
and libyuv::CopyPlane on chromebook atlas, the average cpu duration is
0.624ms and 0.541ms, so using libyuv::CopyPlane is 13.3% faster than
direct memcpy.
Bug: webrtc:12496
Change-Id: I1c41424b402a7eec34052c67933f2e88eaf0a8f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196485
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33344}
This is a follow up to
https://webrtc-review.googlesource.com/c/src/+/200161
I forgot to actually upload the code that addressed reviewer's comments,
and since they were minor comments I went ahead and completed the CL
before I realized.
Fortunately no harm done because all of this code is behind a disabled
build flag. This is a great example of move fast, make mistakes. Lesson
learned.
Bug: webrtc:9273
Change-Id: I5e35b31719b264855568de4b5e595fe0f192654e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204420
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33095}
This change refactors WgcWindowCapturer into WgcCapturerWin, a source
agnostic capturer, and finishes the implementation to enable both window
and screen capture.
This CL depends on another which must complete first:
196622: Add ability to load CreateDirect3DDeviceFromDXGIDevice from
d3d11.dll | https://webrtc-review.googlesource.com/c/src/+/196622
This feature remains off by default behind a build flag, due to it
adding a depency on the Win10 SDK vv10.0.19041 which not all consumers
of WebRTC have upgraded to. A follow up change later will enable the
rtc_enable_win_wgc build flag, but for now it should remain off.
The basic operation of this class is as follows:
Consumers call either WgcCapturerWin::CreateRawWindowCapturer or
CreateRawScreenCapturer to receive a correctly initialized
WgcCapturerWin object suitable for the desired source type.
Callers then indicate via SelectSource and a SourceId the desired
capture target, and the capturer creates an appropriate WgcCaptureSource
for the correct type (window or screen) using the
WgcCaptureSourceFactory supplied at construction.
Next, callers request frames for the currently selected source and the
capturer then creates a WgcCaptureSession and stores it in a map for
more efficient capture of multiple sources.
The WgcCaptureSession is supplied with a GraphicsCaptureItem created by
the WgcCaptureSource. It uses this item to create a
Direct3D11CaptureFramePool and create and start a
GraphicsCaptureSession.
Once started, captured frames will begin to be deposited into the
FramePool. Typically, one would listen for the FrameArrived event and
process the frame then, but due to the synchronous nature of the
DesktopCapturer interface, and to avoid a more complicated multi-
threaded architecture we ignore the FrameArrived event. Instead, we
wait for a request for a frame from the caller, then we check the
FramePool for a frame, and process it on demand.
Processing a frame involves moving the image data from an
ID3D11Texture2D stored in the GPU into a texture that is accessible
from the CPU, and then copying the data into the new WgcDesktopFrame
class. This copy is necessary as otherwise we would need to manage the
lifetimes of the CaptureFrame and ID3D11Texture2D objects, lest the
buffer be invalidated.
Once we've copied the data and returned it to the caller, we can unmap
the texture and exit the scope of the GetFrame method, which will
destruct the CaptureFrame object. At this point, the CaptureSession
will begin capturing a new frame, and will soon deposit it into the
FramePool and we can repeat.
Bug: webrtc:9273
Change-Id: I02263c4fd587df652b04d5267fad8965330d0f5b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/200161
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33083}
Adds a new "rtc_pipewire_version" build option to specify version of
PipeWire we want to build against. We use version "0.2" by default
which is version of PipeWire we currently have in sysroot and which
is supported even on older systems like RHEL7 and Debian.
Bug: chromium:1146942
Change-Id: Ib74b52fa87623a3f960e419916b01586aaeba47f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195441
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32768}
Changes:
1) Scoped class
This is a special class for GLib based objects which we need to manually
delete with different functions. Wrapping these objects into Scoped class
will destroy them automatically when they go out of scope.
2) Window sharing support
Unlike screen sharing, with window sharing we are required to obtain more
information from the PipeWire stream, like video crop metadata, which we
use to properly set size of our buffer.
3) Support for DmaBuf and MemFd buffer types
As of now, we expected the PipeWire stream will provide only plain data
which we just need to copy to our buffer. We now add support for new
buffer types, which are often preferred for better effeciency.
4) Minor bugfixes:
a) Additionally accept PipeWire streams using alpha channels (BGRA, RGBA)
b) Add lock over PipeWire loop to prevent potential issues until we fully
intialize everything we need
c) When obtaining buffers, make sure we work with the latest one
Bug: chromium:682122
Change-Id: I64638d5dcbe18e7280550dca0b01b17c511ac98a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194100
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#32763}
For some time now, calls to EnumerateCapturableWindows could lead to a
deadlock if an application's main thread is waiting on the thread that
is running EnumerateCapturableWindows. This is because calls to
GetWindowText and GetWindowTextLength send a message to the window if
the window is owned by the current process. Since the main thread is
waiting on us, it will never reply to this message and we will hang.
This happens occasionally in Chromium when tearing down the
NativeDesktopMediaList object, e.g. when a user clicks "cancel" on
the capture target picker.
We can avoid this deadlock by checking if the window we are querying
is owned by the current process, and if it is then we must ensure it
is responding to messages before we call a GetWindowText* API.
This change also adds a unit test for this scenario. We create a
window and force it to be unresponsive by creating a deadlock, and
then call GetWindowList and (with the new changes) we should not
hang. Without the new changes to GetWindowListHandler, this test
would hang.
Change-Id: I2523cd735f96fd7ea60708c30cd22e5b525803f0
Bug: chromium:1152841
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195365
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#32734}
* Add OpenOfficeApplicationHandler for MacOS and MS Windows.
* List of available sources for FullScreenWindowDetector on MacOS can include a window with empty title along with titled window for one application.
* List of available sources for FullScreenWindowDetector on MS Windows can include a window with empty title or invisible ones.
Bug: webrtc:11462
Change-Id: Id09537579ef6617dee29759c66dc9f7493166ca8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171723
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Wez <wez@google.com>
Cr-Commit-Position: refs/heads/master@{#32561}
This class used only write locks, no read locks, and hence a plain
mutex is equivalent.
Bug: webrtc:12102
Change-Id: Ia3e52a5cb2db7679a50fca0ab80f85640876d0bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/190720
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32539}
The DxgiOutputDuplicator uses a vector<byte> to hold the rects
that have changed on the screen. It then iterates over the
vector to grab each rect and apply it to the updated_region.
There is vector resizing logic which checks the 'capacity' of
the vector and determines whether there is enough space for the
changed rect data. Often the 'capacity' and 'size' of the
vector are equal but that isn't always true. When the capacity
is greater than size, and the number of changed rects is high
enough, rect data will be written past the element pointed to
by (data() + size()) and this is the error that ASAN is warning
of.
The fix is to use size() instead of capacity() when determining
whether to resize the vector and as the buffer size we provide
to the Windows API. There are no other usages of this vector so
there aren't any problems caused by the size/capacity discrepancy
in the existing builds. The ASAN issue is worth fixing in case
someone comes along and decides to use the vector differently (e.g
rely on the size instead of capacity so some of the rects are
not counted).
Bug: chromium:1138446
Change-Id: I3041091423de889e0f8aabc56ece9466a3000b4f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188900
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/master@{#32425}
The desktop_capture code logs failed HRESULTs in several places,
the problem is that it tries to use a wchar* (when a char*
is required) for the error message and doesn't display the HRESULT
in hex. This makes the error logging less useful than it could be.
Example failure: error 08406B28, with code -2005270488
In this CL, I add a simple utility function to convert a _com_error
object to a std::string whic can be logged. With this change the
output looks like this (linebreak added for CL description):
Failed to capture frame: HRESULT: 0x887A0026,
Message: 'The keyed mutex was abandoned.'
I also adjusted the formatting of a few logging statements to be
more consistent (adding '<<' operators mostly).
Bug: webrtc:12051
Change-Id: I3e88ff6f2ff079fbe210626e1e89b2b053a742a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188522
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/master@{#32417}
This reverts commit 84524e6b196153e35910111f61c36489ec2bd1d7.
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}
Previously windows other than the selected window will also be captured if they share the same process & thread, to allow child windows (e.g. popup menus) to be captured. This could result in child windows of other top-level windows run by the same process and thread being unintentionally captured. In attempt to err on the side of caution this check has been removed leaving some context menus and tooltips not recognized.
Bug: webrtc:11455
Change-Id: I66acc4b133baa51a128202727c655c63b07b19ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176462
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Wez <wez@google.com>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#32395}
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 9b87037073f1811bcdae30967167f30b364e6879.
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}
[1] has introduced two dependencies on
//modules/desktop_capture:pipewire_config
even when rtc_use_pipewire=false, this CL changes the guard in order to
make sure GN doesn't raise errors when is_linux=true and
rtc_use_pipewire=false.
[1] - https://webrtc-review.googlesource.com/c/src/+/160649
No-Try: True
Bug: chromium:682122
Change-Id: I28d2f10936dd75199a2a98862751708eb1e5615a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187122
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32345}
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}
This reverts commit 61709a3233174618d5ab46e1ee5847e4b150c7ef.
Reason for revert: Some downstream projects have issues building this
change due to the inclusion of the <windows.graphics.capture.h> header
which is newly available in the Win 10 SDK v10.0.19041.
To get around this issue for now, this change adds an off-by-default
build flag for these files. However, in the future we will want to
toggle this flag on, and the downstream projects will either need to
update their SDK versions or toggle this flag in their WebRTC clone.
Original change's description:
> Revert "Begin implementing WGC CaptureFrame"
>
> This reverts commit e820cef5340610b9beebbcb63868743b95b97fcd.
>
> Reason for revert: Breaks downstream client. I will investigate and
> get back with a suggestion to fix.
>
> Original change's description:
> > Begin implementing WGC CaptureFrame
> >
> > This change introduces the design that will allow us to deliver frames
> > synchronously to callers despite the Windows.Graphics.Capture APIs being
> > inherently asynchronous.
> >
> > We achieve this by having WindowCapturerWinWgc create and maintain a
> > WgcCaptureSession object for each window that it is asked to capture a
> > frame for. The capture session object will be the class that actually
> > uses the WGC APIs, and it will store the frames it receives in a frame
> > pool and deliver them via GetMostRecentFrame.
> >
> > The next CL will add the necessary functionality to the
> > WgcCaptureSession class.
> >
> > Bug: webrtc:9273
> > Change-Id: I44e164f4874503d8ccc8e6a210e74f9c8458f6c4
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184220
> > Commit-Queue: Austin Orion <auorion@microsoft.com>
> > Reviewed-by: Tommi <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#32240}
>
> TBR=mbonadei@webrtc.org,jamiewalch@chromium.org,tommi@webrtc.org,auorion@microsoft.com
>
> Change-Id: I114944357ce5be7d1e2da817703dc95d544aa99a
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:9273
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186045
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32248}
Bug: webrtc:9273
Change-Id: I9644fbf8f1fd1a84cb716176b8f14e3683a3f7cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186423
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32286}
This reverts commit e820cef5340610b9beebbcb63868743b95b97fcd.
Reason for revert: Breaks downstream client. I will investigate and
get back with a suggestion to fix.
Original change's description:
> Begin implementing WGC CaptureFrame
>
> This change introduces the design that will allow us to deliver frames
> synchronously to callers despite the Windows.Graphics.Capture APIs being
> inherently asynchronous.
>
> We achieve this by having WindowCapturerWinWgc create and maintain a
> WgcCaptureSession object for each window that it is asked to capture a
> frame for. The capture session object will be the class that actually
> uses the WGC APIs, and it will store the frames it receives in a frame
> pool and deliver them via GetMostRecentFrame.
>
> The next CL will add the necessary functionality to the
> WgcCaptureSession class.
>
> Bug: webrtc:9273
> Change-Id: I44e164f4874503d8ccc8e6a210e74f9c8458f6c4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184220
> Commit-Queue: Austin Orion <auorion@microsoft.com>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32240}
TBR=mbonadei@webrtc.org,jamiewalch@chromium.org,tommi@webrtc.org,auorion@microsoft.com
Change-Id: I114944357ce5be7d1e2da817703dc95d544aa99a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9273
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186045
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32248}
