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}
https://webrtc-review.googlesource.com/c/src/+/259457 was a
cherry-pick to M102; as such changes were not made there to keep the
merge to just what had already landed. This addresses the issues raised
on that CL.
Bug: chromium:1316478
Change-Id: I94fad0aa6fe9c67aee5a2f2158524d75b51db48e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259660
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36631}
ChromeOS will use DPI (see crrev.com/c/3322917), but the
DesktopAndCursorComposer assumed pixels were used.
Test: Manually ensured it works
Bug: b/208370410
Change-Id: I5fee50d408fd204273946009e6653d4e60d1e458
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259502
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jeroen Dhollander <jeroendh@google.com>
Cr-Commit-Position: refs/heads/main@{#36597}
While the target has a restricted visibility, since it was in rtc_base_approved
public deps, a lot of targets were able to bypass the visibility check.
So we remove the visibility restrictions and use the dependency explicitely
everywhere instead.
Bug: webrtc:8603
Change-Id: I94a03fdf7f94c54ab72081a58dd648e2cca73d17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258944
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36566}
There is a crash report from the Windows OS API
where it repro only win10, not a Win11.
Unfortunately, Microsoft can't access the dump file or
hasn't repro internally so we decided to disable the WGC
fallback use in the OS other than Win11 now.
Once the change (support WGC fallback) reaches to Microsoft Edge
and it produce crash report, Edge team will take the
dump file to the Windows OS API owner for Win10 level fix (or
bring the Win11 fix to Win10).
Bug: chromium:1312937
Change-Id: I5335e2c57076d4fab08e9c74ade599259cff10d7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258821
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36558}
XDG desktop portal utils implicitly rely on few portal interfaces.
This change makes those interfaces explicit.
Bug: chromium:1291247
Change-Id: I3c300f33d04bfa8857ac9f1f9d634dbfc077e591
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258720
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36557}
Versions of Windows before Win11 will crash when `CreateForMonitor` is
called, but the system has no attached displays. This can be avoided by
adding a check to ensure at least one display is found before we return
true in `IsMonitorValid`. Previously we would early return `true` if the
"monitor" we were checking was the `kFullDesktopScreenId`.
Bug: chromium:1316478
Change-Id: I2562fe3834db574cf3706ee1d604472ac03f9ff3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258920
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36555}
Remote desktop wrapper needs to create a barrier on when the screencast
portal is done (either succeeded or failed). This change adds an initial
enum to differentiate it from other values. CL also generalizes the
helper `PortalFailed` to `OnPortalDone` so as to account for both
failure/success scenarios.
Bug: chromium:1291247
Change-Id: I188f72533e75a88c9b30ce2bb093dae548cef7b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258540
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36526}
The Windows 2019 Enterprise SKU is based on RS5 but is missing support
for WGC. This changes adds a function IsWgcSupported which will check
that the API is actually present, which should be more robust than just
performing a version check.
Bug: webrtc:13932
Change-Id: Ib6a2278f316b9b86671df77fd37468c79564d655
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258163
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36506}
Change adapts the `base_capturer_pipewire` so that a portal can be
injected in the capturer. This allows the remoting to inject its
own portal for the purpose of capturing desktop stream as long
as the injected portal provides implementation of the new interface
that is added as part of this change.
Additionally, a method has been exposed on the capturer to get
details about the portal session so that the remoting
implementation can use the same underlying session for controlling
inputs on the remote host.
Finally, desktop capturer interface is extended with a generic
method `GetMetadata` that is used to retrieve session related
information by CRD and relay it over to its input injector. Clients
provide override for the method and it eventually invokes the
underlying `GetSessionDetails` method on the portal instance.
Bug: chromium:1291247
Change-Id: I0dbd154eb16d4149f967c4a818eea51e7e6eb9a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257000
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36399}
Since 12.2, the orange/red indicator at the top right of the screen shows up as a window in the Chrome getDisplayMedia() picker, as it's not filtered out by the existing filters. Screenshots in the bug.
Bug: chromium:1297731, b/218211225
Change-Id: I0f87e8d2af42a5a2e3d84f69fe73596e9cf35622
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251841
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#36350}
This reverts commit e1223747c27e22c4c4c3006af10d58aec9718b28.
Reason for revert: Breaks WebRTC roll into Chromium. E.g:
https://ci.chromium.org/ui/p/chromium/builders/try/cast_shell_linux/1166014/overview
Original change's description:
> wayland: Add a common interface for screencast and remote desktop portal
>
> Change adapts the `base_capturer_pipewire` so that a portal can be
> injected in the capturer. This allows the remoting to inject its
> own portal for the purpose of capturing desktop stream as long
> as the injected portal provides implementation of the new interface
> that is added as part of this change.
>
> Additionally, a method has been exposed on the capturer to get
> details about the portal session so that the remoting
> implementation can use the same underlying session for controlling
> inputs on the remote host.
>
> Finally, desktop capturer interface is extended with a generic
> method `GetMetadata` that is used to retrieve session related
> information by CRD and relay it over to its input injector. Clients
> provide override for the method and it eventually invokes the
> underlying `GetSessionDetails` method on the portal instance.
>
> Bug: chromium:1291247
> Change-Id: I81b7ce3b949d8be2e24e2d303d5fbc76a849209c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256400
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Commit-Queue: Salman Malik <salmanmalik@google.com>
> Cr-Commit-Position: refs/heads/main@{#36323}
Bug: chromium:1291247
Change-Id: I73fbb1b9a103d61fd8d7f04bb8452b3e29da9025
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256801
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36331}
Change adapts the `base_capturer_pipewire` so that a portal can be
injected in the capturer. This allows the remoting to inject its
own portal for the purpose of capturing desktop stream as long
as the injected portal provides implementation of the new interface
that is added as part of this change.
Additionally, a method has been exposed on the capturer to get
details about the portal session so that the remoting
implementation can use the same underlying session for controlling
inputs on the remote host.
Finally, desktop capturer interface is extended with a generic
method `GetMetadata` that is used to retrieve session related
information by CRD and relay it over to its input injector. Clients
provide override for the method and it eventually invokes the
underlying `GetSessionDetails` method on the portal instance.
Bug: chromium:1291247
Change-Id: I81b7ce3b949d8be2e24e2d303d5fbc76a849209c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256400
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36323}
This is code that will be used to write tests and that makes sense to be
moved out and used somewhere else.
Bug: webrtc:13429
Change-Id: I2dd8f3111fdc9e6fa121c1e18644cbcf340b584e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256009
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36307}
DxgiOutputDuplicator objects hold a reference to the last frame that
they succesfully captured by maintaining a reference to the
SharedDesktopFrame that was passed as their target. This is done because
the DirectX capture APIs may fail to provide an update if there has been
no (or no substantial) change since the last capture call was made.
However, the higher levels of this capture stack
(DxgiDuplicatorController and ScreenCapturerWinDirectX), were unaware of
this, and assumed that the caller of CaptureFrame is the only one who
may have held a reference to the frame. Thus, when CaptureFrame is
called, the DirectX screen capturer assumes that the oldest frame in its
queue can be safely reused.
In the steady state, where capture is not being switched between
monitors, this is fine as there are no competing DxgiOutputDuplicators
being run and this assumption mostly holds true (or the frame is being
overwritten only when the DxgiOutputDuplicator is also done holding it).
However, when capture is being rapidly switched between multiple targets
(e.g. to show a preview of each of the available monitors), this can
result in a frame being held by one DxgiOutputDuplicator being passed to
another as a valid target and overwritten. In the common case of only a
single monitor this is essentially the same as steady state capture,
where there are no competing DxgiOutputDuplicator. In the other common
case of two monitors being captured, the fact that the
ScreenCaptureFrameQueue has two frames ends up masking this issue. Since
each monitor is captured in the same order, the same frame ends up
getting passed to each DxgiOutputDuplicator, so no data actually ends
up getting overwritten. In the case of 3 monitors, the 1st and 3rd
monitor end up sharing a frame, which when capture fails on one of them
surfaces as the other monitor being duplicately shown.
This change addresses the issue by ensuring that each screen that the
ScreenCapturerWinDirectX *actually attempts* to capture, gets it's own
FrameQueue, and thus essentially brings us back to the "steady state"
case for each monitor. Note that this does increase memory usage of
capturers that are switched between multiple targets by 2 frames/target
used (and actually attempted to be captured).
Alternatives considered:
DxgiOutputDuplicator makes a copy of the frame, rather than holding
a reference
This was rejected because adding an additional copy for every
capture upon getting a new frame, would expensive and could degrade
performance.
Allow the DxgiOutputDuplicators to "fail" when there has been no update
This would result in either a breaking change to the API for consumers
or would require the ScreenCapturerWinDirectX to track these last
captured frames; which would result in essentially the same approach,
but with less abstraction for re-using the frames.
Bug: chromium:1296228
Change-Id: I5442ec40e9f234046010b562b258db63693ccc6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256043
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36295}
This CL addresses an issue where the desktop appears to freeze after
resizing the desktop in a curtained CRD session when using the DXGI
capturer. This problem does not reproduce when using the GDI capturer
nor does it reproduce when the Windows session is attached to the local
console.
After digging in, it appears that the DXGI DuplicateOutput API stops
providing updated frame data. No errors are returned but yet no data is
produced. The problem is that when in this condition, there isn't a
good way to discern between this problem and a case where the desktop
is actually static.
The DxgiDuplicatorController already contains logic to attempt to
capture a frame prior to returning success after reinitialization. This
logic works fine in the console case and occasionally works in the
detached session case. What I noticed in my reproductions was that DXGI
would produce a few frames before hanging (usually 1-2 but sometimes 3
or 4). My solution is to check the session state and adjust the number
of frames we attempt to capture (I also simplified the wait logic as
there was a bug in the time calc and it seemed more complicated than it
needed to be).
One option considered would be to introduced a new differ class higher
up in the stack which would run the GDI and DXGI capturers in parallel
(instead of in the fallback configuration as they are today) however
that seemed like overkill for this specific issue.
Bug: chromium:1307357
Change-Id: Idba4bb9b2aa7692040344d480be3f0d09b9ce9e9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256214
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@google.com>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#36286}
Change adds callbacks to the class so that the remote desktop portal can
still make use of this class for selecting sources but can provide its
own implementation on what to do after the sources are selected.
Furthermore, few getters are exposed in the class interface so as to
allow the remote desktop portal class to leverage them when sending the
captured pipewire frames onto the capture stream's consumer. Setters are
added for session, pipewire stream node id and few interfaces are made
public since remote desktop portal relies on them (e.g.
`SelectSources`).
The reason behind the change is that remote desktop portal depends on
screen cast portal for selecting sources. Also the setup to select
devices to control remotely as well as source selection should be
handled as part of the same session (and session should be
instantiated only once).
Currently, starting the screencast portal calls into a callback chain
that not only selects the sources but also starts the session but with
this change a consumer, such as remote desktop portal, can hook into
this callback chain by overriding the callbacks and provide a custom
callback chain from there onwards, if need be.
Bug: chromium:1291247
Change-Id: I983aff062ec2ddf52fdef5545fc58fede416e6ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249862
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36285}
The diff capturer wrapper doesn't work if the frame doesn't have any
rectangle and a static image is observed while chromoting. This change
adds a rectangle to the frame object, as done by other capturers, and
this in turn ensures that the wrapper that calulcates diffs from one
frame to the next can do its job.
Bug: chromium:1291247
Change-Id: I5bf1981f34b3a88ad4d82a081fed1ce210f71ed0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251205
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36263}
Extract helper methods from screencast portal that can be
reused for remote desktop portal client.
Bug: chromium:1291247
Change-Id: I66d09c75f0c34d81c7ceff8998720fbbd1902ac8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249860
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36256}
Check whether there are any cursor metadata before we try to validate
and use them, otherwise we might crash on this.
Bug: webrtc:13429
Change-Id: I365da59a189b6b974cebafc94fec49d5b942efae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/255601
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36240}
