Set cursor position to (-1,-1) to indicate it's not valid when it goes
off the screen or it gets hidden by the compositor. Compositors indicate
invalid or hidden cursor by unsetting the cursor id in cursor metadata
and using spa_meta_cursor_is_valid() will tell us the needed information
for this.
Bug: chromium:346608851
Change-Id: I71b3222ca161b7fd8e964f4f4e12b9983179beba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355080
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#42548}
- avoid holding a lock across OnCaptureResult() callback to avoid a risk
of a possible deadlock
- annotate damage region as guarded by the same lock as latest frame as
both belong together
- document the acqusition order between locks
Bug: chromium:333945842
Change-Id: I9c65beed720ba54e40b85fb243a07d40524695f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353600
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Andreas Pehrson <apehrson@mozilla.com>
Cr-Commit-Position: refs/heads/main@{#42432}
Both CaptureFrame() and ProcessBuffer() hold a lock over the frame queue
and it happens that one waits for the other, causing unnecessary delays
since we already work with a queue having two frames, but this way we
don't really need a queue. Instead, keep reference to the last processed
buffer, which we will always use in CaptureFrame() and update it every
time at the end of ProcessBuffer(). This avoid unnecessary waiting for
the lock over the queue to be released.
Bug: chromium:333945842
Change-Id: I4afeb1daacd342e92578a50ac6e1c89a691bb8f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350042
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#42394}
Use SPA_CHUNK_FLAG_CORRUPTED and SPA_META_HEADER_FLAG_CORRUPTED flags to
determine corrupted buffers or corrupted buffer data. We used to only
rely on compositors setting chunk->size, but this doesn't make sense for
dmabufs where they have to make up arbitrary values. It also looks this
is not reliable and can cause glitches as we end up processing corrupted buffers.
Bug: webrtc:338232699
Change-Id: Ida0c6a5e7a37e19598c6d5884726200f81b94962
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349881
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@{#42292}
Announce that we support SPA_DATA_DmaBuf and tell PipeWire not to map
memory for us so we can handle it ourself, similar like we do in case of
screen sharing. This fixes an issue when a camera is already in use by
gstreamer (pipewiresrc), where DMABufs are used, and we try to share
same camera and get no content, as PipeWire doesn't want to mmap DMABuf
memory for us and we get NULL data pointers.
Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1876895
Bug: webrtc:15654
Change-Id: I788d8d12b2fcd5588329d7265e45b479f74bb628
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/338921
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41826}
Marking capturer as failed will indicate consumers will not be getting
any new frames by sending back ERROR_PERMANENT and let them know that
screencast can be stopped from their side. This will make screencast to
stop when a window we share is closed or when screencast is closed from
system tray.
Bug: chromium:40276865
Change-Id: Ia2c13461bd3126cab9c4838b8aa6840578562e9e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339560
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41817}
Do not automatically remove all tokens once we attempt to use them. This
mitigates an issue with Google Meet where an additional instance of a
DesktopCapturer is created and destroyed right away, taking away the
token we would use otherwise. Also save the token under same SourceId
once we get a new (but could be same) token from the restored session.
Bug: webrtc:15544
Change-Id: I565b22f5bf6a4d8a3b7d6d757f9c1046c7a0557d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322621
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40892}
When PipeWire and xdg-desktop-portals are used, we can actually combine
both source types into one request. Make this part of the API for those
who want to use it this way, e.g. Firefox or Electron, otherwise they
will end up making two simultaneous requests, resulting into two dialogs
at the same time asking, while they can be combined into just one.
Bug: webrtc:15363
Change-Id: Ib6e1e47f66cb01d5c65096aec378b44c3af5f387
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311549
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#40425}
Recently added framerate option can cause a buffer overflow and make
PipeWire to fail on negotiation, which effectively makes screen sharing
not to work.
Bug: webrtc:15346
Change-Id: I4a68e26c8f85ca287b06a25da500b6a7009e075f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311541
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#40413}
We use value -1 on over all the places through our code so it might be
better to define a constant and use it instead to make the code more
understandable on first look.
Bug: webrtc:15203
Change-Id: I4fc3e561bc7a7778c43ec6cfde7acebef2af79e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306620
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40156}
This reverts commit 8856410b6d54b546bdb3185587474f0f9b3a7c2e.
Reason for revert: chromium:1447540
Original change's description:
> pipewire capturer: Reduce the amount of copying
>
> 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}
Bug: chromium:1291247
Change-Id: Id1bfd3fc39fea2bb1f232cad5218f90e144920e7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306263
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40123}
The fcntl() call has variable arguments, therefore we need to pass 0 to
specify there are no other arguments for this call, otherwise we might
end up with an argument that is random garbage.
Bug: webrtc:15174
Change-Id: I34f16a942d80913b667d8ade7eed557b0233be01
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305120
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#40060}
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}
