Improves the capture latency by reducing the amount of
copying needed from the frame. We keep track of the
damaged region of previous frame and union it with
the damaged region of this frame and only copy this
union of the frame over. X11 capturer already has
such synchronization in place.
The change is beneficial especially when there are
small changes on the screen (e.g. clock ticking).
For a 4k screen with 128 cores, I observed the
capture latencies drop from 5 - 8 ms to 0 ms when the
system is left idle. This is in line with the X11
capturer.
Bug: chromium:1291247
Change-Id: Iffb441f9e1902d2658031f5f35b5372ee8e94073
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299720
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39968}
Drop support for old compositors that don't use DmaBufs the way they are
supposed to be used now. There is now a whole negotiation process that
includes DmaBuf modifiers and there is also support for renegotiation in
case we fail to import DmaBufs with certain modifier. This is something
that didn't exist before and in such case, failing to import DmaBufs we
would just end up with broken screen sharing. For that reason it would
be better to use MemFD instead to make sure old compositors will work
just fine
Bug: webrtc:15029
Change-Id: Icc303504e510adc829c12feff7178ae01578a6da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298700
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#39649}
Originally DMABufs were imported into a temporary buffer followed by a
copy operation into the desktop frame itself. This is not needed as we
can import them directly into desktop frames and avoid this overhead.
Also drop support for MemPtr buffers as both Mutter and KWin don't seem
to support them and they are going to be too slow anyway.
Testing with latest Chromium, I could see two processes with usage around 20% and 40% without this change going down to 10% and 20% with
this change applied.
Bug: webrtc:13429
Bug: chrome:1378258
Change-Id: Ice3292528ff56300931c8638f8e03d4883d5e331
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297501
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#39594}
`CopyPixelsFrom` uses libyuv underneath and has handrolled
implementation for copying with AVX.
Bug: chromium:1424776
Change-Id: I4fafeba97fcc1d2200a10070837672175a1dfc50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297800
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39567}
Bug: webrtc:14917
Change-Id: I40e8f011b7263675aab99c452cda8f89ad137cc5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294283
Auto-Submit: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39361}
For frames captured and sent to the callback immediately, we
are not sending the capturer ID as we used to do in base capturer
pipewire. Adding the capturer id as well as the frame capture time
so as to keep the sent frame to be in sync with the
non-immediate-frame-send implementation.
Bug: chromium:1291247
Change-Id: I02693907928b9e770ea56f89b46c37f17f4bc4a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291680
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39228}
Earlier, we were relying on CRD to periodically do frame captures.
This is however not needed since Wayland captures are event based
and once the compositor has send the event/frame to us, we can just
handover the frame to a registered callback. This ensures that we
have a single frame clock that (i.e. one present in the compositor).
Without this change, there is a chance that CRD capture clock is run
out of sync with the compositor's clock and cause unnecessary frame
delays.
See the following ideal scenario, for example, where '+' indicates
when a frame is sent by the compositor and when CRD tries to capture
it. This assumes that the same clock cycle for both CRD and the
compositor, each cycle length is enclosed within | .... |).
Compositor Frame Ready | +... | | +... |
CRD Frame Capture | .+.. | | .+.. |
In this case, when both the clocks are in sync, CRD is able to
capture frame right after it is generated by the compositor. But if
they are completely out of sync, then CRD can always see a stale
frame (delayed by one cycle and it can cause users to feel stutter).
Compositor Frame Ready | .+.. | | .+.. |
CRD Frame Capture | +... | | +... |
This stutter can become worse if the compositor is delayed in
generating the frames for some reason (e.g. load on the system).
Bug: chromium:1291247
Change-Id: I7c10c724fbbd87dc523d474e7ece8e8aa146fd7b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291080
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39218}
This change adds support for renegotiating the frame rate
via pipewire.
Bug: chromium:1291247
Change-Id: Iacd4a3c924900839a8db75a50b448df6c48c83ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291460
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39216}
This CL records the time it took to capture a frame.
Bug: chromium:1291247
Change-Id: I31cbb2ca6ae5b9449b8fd154182105a3ce2c851e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288660
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38933}
Change adds a flag that can be used with desktop capture options
to specify how the cursor capture should be handled.
Bug: chromium:1291247
Change-Id: If8150f8412ade2b6216a65dd026ca528654f52bf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/284780
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38721}
This is a reland of commit e6ec81a89ca904f1816b76456426babc28a9d767
Updated to ensure that the portal code can be built with is_chromeos.
Original change's description:
> Split out generic portal / pipewire code
>
> It will be reused by the video capture portal / pipewire backend.
>
> Bug: webrtc:13177
> Change-Id: Ia1a77f1c6e289149cd8a1d54b550754bf192e62e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263721
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Reviewed-by: Salman Malik <salmanmalik@google.com>
> Cr-Commit-Position: refs/heads/main@{#38487}
Bug: webrtc:13177
Change-Id: I2c890c83c86ad60fa30f63dcf6fa90510d46009e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281661
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38620}
It appears to be still failing occasionally so add one more event
to verify streams connected successfully in order to verify whether
we sent and received buffers properly in the next step.
Bug: webrtc:14644
Change-Id: I08822b15452fc845d68cbff1b01ae6b6f7c1f486
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282842
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#38598}
This CL will also make PipeWire tests retried 3 times in case of failures.
Change-Id: I9c66351f7ee171e29266fe4b8dcd52ca282c8f6d
Bug: webrtc:14644
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282820
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38595}
This reverts commit e6ec81a89ca904f1816b76456426babc28a9d767.
Reason for revert: Assert on line 14, modules/portal/BUILD.gn breaks in downstream build. Reverting until it has been investigated.
Original change's description:
> Split out generic portal / pipewire code
>
> It will be reused by the video capture portal / pipewire backend.
>
> Bug: webrtc:13177
> Change-Id: Ia1a77f1c6e289149cd8a1d54b550754bf192e62e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263721
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Reviewed-by: Salman Malik <salmanmalik@google.com>
> Cr-Commit-Position: refs/heads/main@{#38487}
Bug: webrtc:13177
Change-Id: I18deb5c78a54261f77693e7e31dba6f98f5eeb5d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280947
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Björn Terelius <terelius@webrtc.org>
Auto-Submit: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38496}
It will be reused by the video capture portal / pipewire backend.
Bug: webrtc:13177
Change-Id: Ia1a77f1c6e289149cd8a1d54b550754bf192e62e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263721
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#38487}
This doesn't effect for how long the test will run, it just gives
PipeWire more time to establish connection and create empty buffers
before we try to work with it. All the waiting events will be
interrupted by signals once we no longer need to wait so it doesn't
matter if we wait 2 seconds or 5 seconds.
Bug: webrtc:14568
Change-Id: Ie918e8943bf882059b1289f57595fc302216745e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280700
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#38486}
It doesn't really make sense to try to create the X11 capturer if we are
running under Wayland; nor does it make sense to create the PipeWire
capturer if we are going to fail to actually start a stream with it.
This change addresses both of these issues by exposing an IsSupported
method on BaseCapturerPipeWire and checking that we are not running
under Wayland before creating the X11 capturer.
Bug: chromium:1374436
Change-Id: Ieb291307376010e084824124ea8fde065545337c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279163
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38474}
Remove useless comments and properly test frame values. Also rename the
FakeScreenCastStream to TestScreenCastStreamProvider.
Bug: webrtc:13429
Change-Id: I9b1943f0903101a1d9228cded541d3766879d84f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279740
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#38450}
We already communicated SPA_META_VideoDamage before, but we never used
these metadata. This change checks whether SPA_META_VideoDamage metadata
are available and construct a damage rect combined from all sent damage
regions.
Bug: webrtc:13429
Change-Id: I326109b4bacf51855904e53345c671640d670323
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278820
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#38449}
This test created another PipeWire stream we can connect to with
SharedScreenCastStream and recieve frames from there. This is an
initial version, where I test whether we can successfuly connect
and disconnect, receive frames and it also tests DesktopFrameQueue.
In the future I will add tests to test mouse cursor and try to
come up with some corner cases and possible scenarios.
Bug: webrtc:13429
Change-Id: Ib2a749207085c6324ffe3d5cc8f2f9c631fa6459
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256267
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38431}
Libdrm is an essential library and should be available everywhere where needed. It also looks it's a dependency for Chromium already.
Bug: webrtc:13429
Change-Id: Id81497b4f29bbd80f7d94f57333aa533288c3538
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279023
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38392}
This is a speculative fix for the DCHECK at the top of
ScreenCapturerX11::CaptureScreen(). Whenever |selected_monitor_rect_|
changes, |queue_| should be reset, so that new frames are allocated
with the correct size. This CL adds a reset to UpdateMonitors() which
modifies |selected_monitor_rect_| and is called whenever an X11
configuration-change event is received (for example, when a monitor is
resized).
Bug: chromium:1372579
Change-Id: I9cc84a8b6990802f9d7dde05966ee17a80ddd48e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279065
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Auto-Submit: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38374}
This makes the implementation in line with the existing X11
implementation:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/desktop_capture/linux/x11/screen_capturer_x11.cc;l=240-243
The issue I am observing on slightly slower machines with 4k monitor
is that the frames tend to go back in time. I believe this happens
when the shared frame queue is full and has its frame shared. When
that happens, we still end up calling MoveToNextFrame and doing so
we will wrap around the queue and if the capturer captures a frame
again, it sees an older frame. This is causing screen glitches.
This CL normalizes the implementation with X11 (which is known to
work fine) and moves to next frame and always uses it. This helps
to keep the current_frame_ in sync for the caller / capturer and
the capturer will then always see the video moving forward.
On the same machine, these screencasts were taken:
Without this fix: https://youtu.be/7Toi8dL5eYw
With this fix: https://youtu.be/LOE8Si5iOuQ
Bug: chromium:1291247
Change-Id: I51d3d700d3417d31371b12a94f445fc7b530cf73
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278700
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38342}
Shared screencast stream is tied to desktop capturer options,
which may outlive capturer itself. This leads to a case where
one may attempt to restart the stream in the capturer. This
causes the previous pipewire objects to leak (as observed
in `pw-top` output) and seems to appear as frozen screen for
clients. This CL ensures that the shared screen cast stream,
which is started in this capturer, is also stopped when the
capturer is destroyed.
Bug: chromium:1291247
Change-Id: I5f2b22e54e916549a5280ec457cd76360e42e48a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276640
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38187}
Chrome Remote Desktop will support both X11 and Wayland desktop
capturers in the near future and we'd like to differentiate between
the two in our video frame stats and telemetry. I beleive other
products are in a similar position so I would like to add a capturer
ID to the frames generated by the capturer classes.
Bug: chromium:1366062
Change-Id: If27c35ad6ef89b6396120982edc4dd0cf2a1e51c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276081
Commit-Queue: Joe Downing <joedow@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38185}
https://crrev.com/c/3885576 removed the last downstream consumer of the
constructor which took a ScreenCastPortal::CaptureSourceType. Now that
it has been removed, that constructor definition can also be removed and
the CaptureSourceType enum can be made private. There's still benefit in
storing and using this internally as the enum, since it's values match
that of the underlying system API.
The previously anonymous-namespaced function |ToCaptureSourceType| had
to be converted to a private static method as part of this change, since
it would be unable to access the type otherwise.
Fixed: chromium:1359411
Change-Id: I81ff24fbdddf9db02c9c5152d007dd82c194865a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274680
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38084}
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 0098a441e3990f80bcbe05dfce8c6e2359f7ef25.
Reason for revert: Fix chromium build break
Original change's description:
> Revert "Add plumbing to control PipeWire picker visibility"
>
> This reverts commit fbea8c519684577a38cb35b9287ba4645a905094.
>
> 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 fbea8c519684577a38cb35b9287ba4645a905094.
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}
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}
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}
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}
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}
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}
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}
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}
