I've added the proper headers to the only file in Chromium which includes screen_capture_frame_queue.h (see https://chromium-review.googlesource.com/c/chromium/src/+/3836317).
I've also built the remoting host and Chrome on Windows and Linux with this change and did not see any build errors.
The only build error I encountered was in shared_screencast_stream when building webrtc so I added the required header there.
Bug: webrtc:14378
Change-Id: Ie88e606dfa52f18514a87b87e5904424543d7df3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271922
Commit-Queue: Joe Downing <joedow@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37811}
When ScreencastPortal::OnStartRequestResponseSignal receives either a
non-zero response code or is missing the response data, it would
directly cast this to a RequestResponse. However, this direct cast is an
error. Per the documentation, the response signal returns the following
values with their corresponding meanings:
0 - Success
1 - User Cancelled
2 - Error
The RequestResponse enum however, has "kUnknown" as 0, and thus
"kSuccess" as 1 (with all other values also shifted up by 1 value). This
means that when the portal was cancelled, we were still receiving
RequestResponse::kSuccess. This fixes the issue by removing the improper
cast and adding a translation function. This function is local for now
since no where else attempted to cast values to a RequestResponse; but
can be moved if the need arises.
Fixed: chromium:1351824
Change-Id: I4cd44d90055147c9592d590c7969dcfc3297a3d9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271240
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37755}
We pass the fd we recieve from xdg-desktop-portal to PipeWire to connect
to it and according to the specification PipeWire automatically closes
it on disconnect or failure. We also close the fd ourself when we tear
down the portal connection so we have to avoid doing this twice. Looks
OBS studio just duplicates the fd passed to PipeWire so do the same in
order to avoid the fd ownership violation once we stop sharing.
The fd we recieve from xdg-desktop-portal is from PipeWire also using
fcntl() with F_DUPFD_CLOEXEC option.
Bug: chromium:1339236
Change-Id: Ia7aee36e520dd5ff9a40688a6807e31c4e636f8e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270421
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37712}
Before this change the full screen application handler was failing to
detect PowerPoint going into presentation mode, resulting in the editor
window continuing to be shared rather than the intended behavior of
sharing the presentation itself.
Fix this by always looking for the PowerPoint full screen presentation
window, regardless of whether the editor window is still open. In
the current version of PowerPoint, the editor stays open during
presentation.
Bug: chromium:1231437
Change-Id: I1b21e263d25320cc236d127d22d4d64bb52fcbda
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269560
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37632}
This overload was removed in C++20.
Bug: chromium:1284275
Change-Id: I67a25ae23fa111e4972d1b207f1c078da13d86a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269440
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37630}
Consumers expect the frame to be valid if Result::SUCCESS is delivered.
If the frame is nullptr, we should deliver ERROR_TEMPORARY instead.
Bug: webrtc:14265
Change-Id: If94a3ead38d7657d7b90bbe046256be697312216
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269223
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37590}
There is a AV where GDI capturer sends empty frame to the
blank detector. It is fine operation from the GDI capturer
to pass an empty to the next handler. So, blank capturer
filter it and send it as blank frame to next handler.
Bug: webrtc:14265
Change-Id: Ifc90a210703e14fa6d0dc7fb2ae2942ae4e8125f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/268444
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37513}
This reverts commit dd32562f242b247aed8add4efecaf3e20c623b9a.
Reason for revert: Updated the original change to dynamically load
the CoreMessaging.dll instead of statically linking with the .lib.
Original change's description:
> Revert "Wait for frames to arrive in WgcCapturer instead of returning nothing."
>
> This reverts commit 93bb3051490253d56dc1cdab4701b91138a151c3.
>
> Reason for revert: It breaks a test while rolling into Chromium,
> see https://webrtc-review.googlesource.com/c/src/+/261780/21#message-4a96e33bfb475f19a618be82bbe72951b23085ef for details.
>
> Original change's description:
> > Wait for frames to arrive in WgcCapturer instead of returning nothing.
> >
> > We're seeing a high instance of "first capture failed" in Chromium when
> > using WGC. We can reduce this by waiting for frames to arrive if there
> > are none in the frame pool instead of returning a temporary error.
> >
> > I've set the maximum time to wait for a frame to 50ms. If no frame
> > arrives before 50ms has elapsed, we will return a temporary error.
> > Added a new test, FirstCaptureSucceeds, to verify that this is working
> > as expected.
> >
> > As part of this I updated the name of the `kCreateFreeThreadedFailed`
> > enum value to `kCreateFramePoolFailed`. The value remains the same
> > since they both report failures in frame pool creation.
> >
> > I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
> > store two frames. This should prevent us from having to wait on the
> > event as frequently. This will increase the latency between capture
> > and display, however. High frame rate applications should not be
> > noticeably affected.
> >
> > Additionally, we uncovered a bug in the OS that prevents window capture
> > when there are displays attached, but none of them are active. Added
> > a new check to `IsWgcSupported` to cover this scenario.
> >
> > Finally, some issues with other WGC tests blocked moving the TryBots
> > to a newer version of Windows. This CL fixes those issues and updates
> > the TryBot configuration.
> >
> > bug: chromium:1314868
> > Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
> > Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> > Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> > Commit-Queue: Austin Orion <auorion@microsoft.com>
> > Reviewed-by: Jeremy Leconte <jleconte@google.com>
> > Cr-Commit-Position: refs/heads/main@{#37404}
>
> Change-Id: If237df4826fe20b6fe2ca4b57253623321bf33c5
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267460
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37408}
Change-Id: I6cc2becd9ed363782ab2f326f58d9401bc8fb820
Bug: chromium:1314868
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267902
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#37470}
This reverts commit 93bb3051490253d56dc1cdab4701b91138a151c3.
Reason for revert: It breaks a test while rolling into Chromium,
see https://webrtc-review.googlesource.com/c/src/+/261780/21#message-4a96e33bfb475f19a618be82bbe72951b23085ef for details.
Original change's description:
> Wait for frames to arrive in WgcCapturer instead of returning nothing.
>
> We're seeing a high instance of "first capture failed" in Chromium when
> using WGC. We can reduce this by waiting for frames to arrive if there
> are none in the frame pool instead of returning a temporary error.
>
> I've set the maximum time to wait for a frame to 50ms. If no frame
> arrives before 50ms has elapsed, we will return a temporary error.
> Added a new test, FirstCaptureSucceeds, to verify that this is working
> as expected.
>
> As part of this I updated the name of the `kCreateFreeThreadedFailed`
> enum value to `kCreateFramePoolFailed`. The value remains the same
> since they both report failures in frame pool creation.
>
> I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
> store two frames. This should prevent us from having to wait on the
> event as frequently. This will increase the latency between capture
> and display, however. High frame rate applications should not be
> noticeably affected.
>
> Additionally, we uncovered a bug in the OS that prevents window capture
> when there are displays attached, but none of them are active. Added
> a new check to `IsWgcSupported` to cover this scenario.
>
> Finally, some issues with other WGC tests blocked moving the TryBots
> to a newer version of Windows. This CL fixes those issues and updates
> the TryBot configuration.
>
> bug: chromium:1314868
> Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> Commit-Queue: Austin Orion <auorion@microsoft.com>
> Reviewed-by: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#37404}
Change-Id: If237df4826fe20b6fe2ca4b57253623321bf33c5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267460
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37408}
We're seeing a high instance of "first capture failed" in Chromium when
using WGC. We can reduce this by waiting for frames to arrive if there
are none in the frame pool instead of returning a temporary error.
I've set the maximum time to wait for a frame to 50ms. If no frame
arrives before 50ms has elapsed, we will return a temporary error.
Added a new test, FirstCaptureSucceeds, to verify that this is working
as expected.
As part of this I updated the name of the `kCreateFreeThreadedFailed`
enum value to `kCreateFramePoolFailed`. The value remains the same
since they both report failures in frame pool creation.
I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
store two frames. This should prevent us from having to wait on the
event as frequently. This will increase the latency between capture
and display, however. High frame rate applications should not be
noticeably affected.
Additionally, we uncovered a bug in the OS that prevents window capture
when there are displays attached, but none of them are active. Added
a new check to `IsWgcSupported` to cover this scenario.
Finally, some issues with other WGC tests blocked moving the TryBots
to a newer version of Windows. This CL fixes those issues and updates
the TryBot configuration.
bug: chromium:1314868
Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#37404}
For this I added a header called no_cfi_icall.h and use it.
Also, some files use the gio header, but if the //base dependency is
not used, compilation errors occur. So I added an explicit dependency
on gio.
Bug: webrtc:13662
Change-Id: If732ede202dd413be6702bf06bf024cd203fdae2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267340
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37395}
In commit a6ed749b12c63d252c6d893d5b5b62fcf35773d9 we used width of the
frame we copy into to calculate the source stride. This is a wrong
assumption as there might be implementations (e.g. GNOME) where we might
have to import a DMA-BUF with size of the whole screen and just having
information in SPA_META_VideoCrop metadata to get the real size of the
frame we will end up using. Given this, we always have to calculate
source stride using the size of the stream to not end up copying pixels
from the empty area of the imported DMA-BUF.
Also improve naming of variables to have names better describing what
they really represent and add some comments explaining why some things
are written the way they are.
Bug: chromium:1333304
Change-Id: I755a5139336c1da5abf95591a2b70a68659a255f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267002
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37344}
It's not a problem if we fail to query DMA-BUF modifiers as we can still
continue with modifier-less buffers.
Bug: webrtc:13429
Change-Id: Ia718362bdc9eef1ebc54c06b24a2b65206aa873e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267003
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#37342}
This CL removes the split of "desktop_capture" in 2 build targets
(one for C++ and one for Obj-C++) by moving the C++ part to
"desktop_capture" itself and keeping the Obj-C++ variant but allowing
it to include .h files that are also part of "desktop_capture".
This removes the build cycle between the two targets (which conceptually
are the same target).
Clients should never depend on "desktop_capture_objc", which will
be linked by "desktop_capture" when needed.
Bug: b/36882554
Change-Id: Id219a15e549275870c54375c07f00cfe704ab7cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266743
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Oleh Prypin <oprypin@google.com>
Cr-Commit-Position: refs/heads/main@{#37337}
When a display uses a scale factor (different than 1.0) the previous
cursor position is not properly cleared during a CRD connection on
ChromeOS (see b/235191365).
The issue was that the fix for crbug.com/1323241 does not take device
scaling into account, so that fix would incorrectly not mark the
previous location of the mouse cursor as modified.
Adding proper boundary checks is hard and risky though, as the way the
position of the mouse cursor is reported seems to be platform dependent
(ChromeOS vs Linux vs ...).
So because crbug.com/1323241 only solves a theoretical crash that is rarely if
ever hit in the field, I decided to for now undo the fix for crbug.com/1323241.
A proper boundary check can then later be introduced without any pressure from
a looming release
Bug: chromium:1323241
Bug: b/235191365
Fixed: b/235191365
Test: Manually deployed
Change-Id: Ib09b6cc5e396bd52538332edfc4395ed80c6786e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265391
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Joe Downing <joedow@google.com>
Commit-Queue: Jeroen Dhollander <jeroendh@google.com>
Cr-Commit-Position: refs/heads/main@{#37274}
Make use of "persist_mode" option in ScreenCast portal to restore
previously selected screen/window and avoid picking it again in yet
another xdg-desktop-portal dialog.
Bug: webrtc:13429
Change-Id: I3a0068091c2dd38003a7dff3f82b9cdb2ccd0f42
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263901
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37257}
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}
When DMA-BUFs are used, sometimes stride we get from PipeWire might
contain additional padding, but after we import the buffer, the stride
we used is no longer relevant and we should just calculate it based on
width.
Bug: chromium:1333304
Change-Id: Id4300550f0b3c539ddd749e9285f525d4f816b80
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265384
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37195}
Bug: chromium:1330019
Change-Id: I1a22967dff3231c1522fb94de38b309f441d468e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265442
Reviewed-by: Frank Barchard <fbarchard@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#37158}
This reverts commit 0ba10283fb3cbdf1cedea79d84e4bc3b720da6a1.
Reason for revert: This workaround is no longer needed, as the libyuv team has already fixed the underlying issue (in b/234824290)
Original change's description:
> Fix memory corruption in BasicDesktopFrame::CopyTo
>
> This memory corruption happens inside libyuv::CopyPlane()
> on platforms that support AVX. I opened b/234824290 so the libyuv team
> can investigate and fix this, but in the mean time we need to get this
> fixed asap as this is causing crashes on both M102 (which is released to
> stable) and M103 (which has this issue marked as beta blocking).
>
> Fixed: b/234824290
> Fixed: chromium:1330019
> Test: Manually reproduced on zork board
> Change-Id: I6bfd1e089020dfb23d974d3912d45c01a4e5ce26
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265041
> Auto-Submit: Jeroen Dhollander <jeroendh@google.com>
> Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#37121}
Fixed: b/234824290
Fixed: chromium:1330019
Change-Id: Iafc0eac651fbc7a7fce5092306b12c4377248839
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265165
Auto-Submit: Jeroen Dhollander <jeroendh@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Frank Barchard <fbarchard@google.com>
Cr-Commit-Position: refs/heads/main@{#37142}
This memory corruption happens inside libyuv::CopyPlane()
on platforms that support AVX. I opened b/234824290 so the libyuv team
can investigate and fix this, but in the mean time we need to get this
fixed asap as this is causing crashes on both M102 (which is released to
stable) and M103 (which has this issue marked as beta blocking).
Fixed: b/234824290
Fixed: chromium:1330019
Test: Manually reproduced on zork board
Change-Id: I6bfd1e089020dfb23d974d3912d45c01a4e5ce26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265041
Auto-Submit: Jeroen Dhollander <jeroendh@google.com>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37121}
This change adds support for dynamic resolution adjustment
of pipewire stream.
Bug: chromium:1291247
Change-Id: I87e02484920f795a053a814eb872834ab22c1bd3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263680
Commit-Queue: Salman Malik <salmanmalik@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37010}
u8"" no longer produces a char*. Use "" instead, which also accepts
UTF-8 literals.
Bug: chromium:1284275
Change-Id: Ida84b82670eb1238a606d3fe8c4eb40fbc23165e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263760
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37005}
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}
PipeWire server in older versions would mark the negotiation as
finished and start creating buffers.
Upstream bug: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1732
Bug: webrtc:13429
Change-Id: I7194e6672716d7fef1c2aadc40d3acf55cb282a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262621
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36901}
HandleXEvent() returns true to indicate the event is consumed and
should not be passed to other registered handlers of the same
event-type.
In ScreenCapturerX11, this makes sense for XDamage events because they
are scoped to the object's |damage_handle_|. But RRScreenChangeNotify
and ConfigureNotify events are scoped to the root window, so this CL
changes the return value to false for these events. This allows other
handlers (including other screen-capturer instances) to see these
events.
Bug: webrtc:14060
Change-Id: Id18917b0b62d125da08578e08df9648062500cad
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262142
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36858}
This allows builds on non-x86 architectures such
as ppc64el.
Bug: webrtc:14057
Signed-off-by: Timothy Pearson <tpearson@raptorcs.com>
Change-Id: Ie2c1023d2c1d041ba1d140f06af432ed9e9f7432
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262002
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36856}
Apple renamed CGColorSpaceCopyICCProfile to CGColorSpaceCopyICCData in
10.13. If you compile code with a minimum OS required of 10.13 or
newer, [-Werror,-Wdeprecated-declarations] will cause an error to
occur on use of the function with the old name.
Add a compile switch so that no error is emitted regardless of the
deployment configuration.
Bug: chromium:1322548
Change-Id: Ie969aa9e5c4fc9bee2ec88b126d4c07701c3e9e6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261953
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36855}
This crash happened when:
* The cursor was located in the corner
* The screen was resized so that the cursor position is outside of the frame.
This caused us to add out-of-bound coordinates to the frame's updated_region, which caused crashes further down the pipeline.
Bug: chromium:1323241
Test: new unittest
Test: manually reproduced crash
Change-Id: Ie71db58c8a347f00af8a3803fcd55cdcad6eafac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261263
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jeroen Dhollander <jeroendh@google.com>
Cr-Commit-Position: refs/heads/main@{#36809}
Several tests starting failing when run on trybots on Win10. This CL
fixes several issues that were uncovered.
Issue 1:
Capture failed to start because `get_Size` returned {0, 0}. This is a
known issue in the WGC API that occurs when there are multiple user
sessions on the same machine.
Solution:
Add a `GetSize` method to the `WgcCaptureSource` interface so we can
fallback to other methods if `get_Size` fails.
Issue 2:
The screen capture tests assume there will be displays attached and
fail if there aren't.
Solution:
Always run `IsWgcSupported` for the appropriate capture type.
Issue 3:
ASAN container-overflow in `GetTestWindowIdFromSourceList`
Solution:
Check the validity of the iterator before dereferencing.
Issue 4:
Occasionally, the call to `GetMessage` in the `CloseWindowMidCapture`
test would hang because there were no messages in the queue.
Solution:
Use `PeekMessage` instead which will return if there are no messages.
Bug: webrtc:14002
Change-Id: I69b2f765db87d34a41d6a1796cd5a81f4029be33
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260202
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36802}
We already use RTC_NO_SANITIZE("cfi-icall") for most of the code and
it looks this one can be triggered recently with pw_loop_signal_event()
call.
Bug: webrtc:13659
Change-Id: I4dbb88f32de861e05be18254640db90b0f58c5e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261300
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36787}
