Now that we've added the ability to open and close the PipeWire picker
to the DesktopCapture interface, we can split the picker back into a
Window and a Screen picker rather than just having the one combined
picker. This will allow for a better user experience, as we can create
a picker targeted to what the users actually want to share.
Bug: chromium:1351570
Change-Id: I5bec22912ae01c1b0b0709a4979b4698226a2a66
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273541
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38000}
Adds an Observer class to the DelegatedSourceListController so that we
can expose user-driven events from the delegated source list. This will
allow embedders to update their UI in response to changes to the state
from the delegated source list. Currently these events are: selection,
cancelled, and error.
Bug: chromium:1351576, chromium:1351577
Change-Id: I248bdb1c4410147ca1a0663eafda40b6b9345801
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272622
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37986}
This will allow to catch issues (like the one that caused the revert
[1]) at CQ time.
[1] - https://webrtc-review.googlesource.com/c/src/+/273486
Bug: None
Change-Id: Ib12c15dcdc3e2a358d40c1a2ffabfbf42274e978
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273660
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37982}
This reverts commit 0098a441e3.
Reason for revert: Fix chromium build break
Original change's description:
> Revert "Add plumbing to control PipeWire picker visibility"
>
> This reverts commit fbea8c5196.
>
> Reason for revert: Breaks WebRTC import into Chromium, e.g:
> https://chromium-review.googlesource.com/c/chromium/src/+/3863998/
>
> Original change's description:
> > Add plumbing to control PipeWire picker visibility
> >
> > Introduces the notion of a "delegated source list" and corresponding
> > controller. This is used by desktop capturers (currently just the
> > PipeWire capturer), who control selecting the source through their own
> > (often system-level) UI, rather than returning a source list with all
> > available options that can then be selected by the embedder.
> >
> > Adds a method to get the controller which serves to also tell embedders
> > if the capturer makes use of a delegated source list. The controller
> > currently allows the embedder to request that the delegated source list
> > be shown or hidden, and will in the future be used to expose events
> > from the source list (e.g. selection, dismissal, error).
> >
> > Bug: chromium:1351572
> > Change-Id: Ie1d36ed654013f59b8d9095deef01a4705fd5bde
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272621
> > Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> > Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#37956}
>
> Bug: chromium:1351572
> Change-Id: I06f76ab9c8bc1aa303dae177d48698951fdc5ecd
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273703
> Auto-Submit: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37964}
Bug: chromium:1351572
Change-Id: I9e5e691746b81517bf0e211d0ad5a23371ab29ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273685
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37972}
This reverts commit fbea8c5196.
Reason for revert: Breaks WebRTC import into Chromium, e.g:
https://chromium-review.googlesource.com/c/chromium/src/+/3863998/
Original change's description:
> Add plumbing to control PipeWire picker visibility
>
> Introduces the notion of a "delegated source list" and corresponding
> controller. This is used by desktop capturers (currently just the
> PipeWire capturer), who control selecting the source through their own
> (often system-level) UI, rather than returning a source list with all
> available options that can then be selected by the embedder.
>
> Adds a method to get the controller which serves to also tell embedders
> if the capturer makes use of a delegated source list. The controller
> currently allows the embedder to request that the delegated source list
> be shown or hidden, and will in the future be used to expose events
> from the source list (e.g. selection, dismissal, error).
>
> Bug: chromium:1351572
> Change-Id: Ie1d36ed654013f59b8d9095deef01a4705fd5bde
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272621
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#37956}
Bug: chromium:1351572
Change-Id: I06f76ab9c8bc1aa303dae177d48698951fdc5ecd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273703
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37964}
We might be potentially blocking PipeWire initialization with call to
pw_thread_loop_wait() and waiting undefinitely for response in case
there is a fatal error.
Bug: webrtc:13429
Change-Id: If169e04f75a7d24a03a0fcd0da9ffaba8c0e2ef7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273481
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37959}
Introduces the notion of a "delegated source list" and corresponding
controller. This is used by desktop capturers (currently just the
PipeWire capturer), who control selecting the source through their own
(often system-level) UI, rather than returning a source list with all
available options that can then be selected by the embedder.
Adds a method to get the controller which serves to also tell embedders
if the capturer makes use of a delegated source list. The controller
currently allows the embedder to request that the delegated source list
be shown or hidden, and will in the future be used to expose events
from the source list (e.g. selection, dismissal, error).
Bug: chromium:1351572
Change-Id: Ie1d36ed654013f59b8d9095deef01a4705fd5bde
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272621
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37956}
The libyuv fix for this issue was submitted > 2 months ago so it
should be safe to remove the workaround from webrtc.
Bug: chromium:1330019
Change-Id: Ibcf3818739673005e40d7ef9917c5f5692c50df4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272861
Commit-Queue: Joe Downing <joedow@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37895}
I would like to run a separate capturer for each desktop on Linux and
I ran into the DCHECK in XErrorTrap when I was prototyping that
solution. I addressed it by using a Mutex and then experienced and
occasional hang when capturing which I traced down to
SharedXDisplay::ProcessPendingXEvents(), this is a shared display
instance used by each unique capturer instance so I added a mutex
there as well.
I ran 2 capturer instances concurrently for well over an hour and did
not experience any hangs or capture artifacts.
Bug: webrtc:2022
Change-Id: Ia6778cae4bbae48886fe45f2991f02e0ea08fef6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271920
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#37892}
In case ScreenCast portal fails right at the beginning, we need to check
the response before trying to get session handle to avoid accessing
non-existing portal data.
Also on early failure do not continue making source request if we failed
before and don't have session handle.
Bug: webrtc:13429
Change-Id: I2bfbd2c6e96e3cda1e62aa9dc07f66d4c7496b53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272400
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37872}
This is a follow up to this CL
https://webrtc-review.googlesource.com/c/src/+/269223
which unintentionally prevents the WindowCapturerWinGdi from returning
permanent errors.
Bug: webrtc:14265
Change-Id: I8eb9f8852fb6247a045d32e407ebdd5f45e6aa9d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271880
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37847}
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 dd32562f24.
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 93bb305149.
>
> 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 93bb305149.
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 a6ed749b12 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 0ba10283fb.
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}
