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 is a partial revert of the previously landed CL in
https://webrtc-review.googlesource.com/c/src/+/301200.
I noticed when I used `getDisplayMedia` on my private Windows laptop
in combination with WGC that the captured screen was distorted and
did only contain tilted (~35 degrees) lines in all sorts of colors.
The issue only happened for one particular screen resolution
3000 x 2000 and 200% scale. Changing to 100% scale instead resolved
the issue.
I tried many other resolutions but could only trigger for the one
above with 200% scaling.
Next, I bisected and found [1] which led to [2] which contains my own
change in https://webrtc-review.googlesource.com/c/src/+/301200.
The only part that could affect the video frame was the part which
did `CopyPixelsFrom` so I reverted that part and it solved the issue
on my private Windows laptop.
I did not dig deeper into why this particular resolution triggered
the distortion but deiced to revert to avoid more reports.
[1] b4c2a7fcf5..ff848b7a43
[2] a9a2957dbc
Bug: chromium:1428592
Change-Id: I328e77840cd3ca6871254cdf06500bdc616b0c36
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306600
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40147}
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}
* Removes a ~60Hz thread-wakeup signal caused by the FrameArrived event
* Initial power measurements shows a reduced power consumption
* No increase in time to first captured packet found
Bug: chromium:1428592
Change-Id: Ia23b5db0c87e70e5b0d6919394494a24d8944493
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301200
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39861}
This CL removes the usage of the Magnifier screen capture API on
Windows. The idea is to remove the actual source in a second step
once this change lands.
Bug: chromium:1428341
Change-Id: Id2cb25632c7edbea2cf527959b14b27ee00b0e56
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301164
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39856}
The idea is to land this in Canary and ask for feedback from users
who can reproduce the issue, solve the issue and then revert this CL.
Example: https://paste.googleplex.com/6080504230051840
Bug: chromium:1421656
Change-Id: Ic214dc341a322470970abeca1794493f45b93843
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301080
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39834}
Bug: chromium:1431897
Change-Id: Ib871dc22d2cf93180d7aa05016e34ffec944d73e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301040
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39830}
Before:
No attempt was made to figure out of the cursor was embedded into the
captured video frame when using DXGI on Windows as screen capturer.
Instead the cursor is superimposed on the frame by an external mouse
and cursor composer.
After:
We now check if the display adapter supports embedding the mouse
cursor and if so use it as is and thereby avoid adding it independently.
Bug: chromium:1421656
Change-Id: Ie07fe13e1c8f9583769961328bb41fbc689cd8e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299241
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39742}
This change makes it more clear that there are three different
capture API combinations for screen sharing on Windows.
No option => GDI without fallback.
DirectX option => DirectX with GDI as fallback
Magnifier option => Magnifier API with GDI as fallback
Previously, if both DirectX and Magnifier were enabled, the end
result was Magnifier for unknown reasons.
With this change in place, we can remove usage of the Magnifier API
in Chrome and switch between DirectX and GDI simply by allowing
DirectX or not.
Bug: None
Change-Id: Ice915d6721fa84a25d275f22246df73fc61f64b5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299061
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39692}
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}
Logs if the mouse cursor has moved and if so if it is embedded in the
captured DXGI frame or not.
Bug: chromium:1421656
Change-Id: Ic8fa8a5a3c020ec28b04064c765b1c204accec1c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298564
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39644}
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}
* Avoids alloc/dealloc for each captured frame.
* Reduces time to capture first frame.
* Improves performance in terms of max FPS.
Bug: chromium:1412584
Change-Id: Ie16519ad788165c9553451ecea5adff12cd15eea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293582
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39384}
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}
The histogram WebRTC.Screenshare.DesktopCapturerFullscreenDetector
incorrectly counted every time a presentation application was shared
instead of only counting sessions where the presentation was
presented in fullscreen. This bug affected Windows, macOS works as
intended.
Bug: chromium:1348011
Change-Id: I9e84e9d1f4310703ba94e2af2e35a52d74a25842
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293461
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39314}
I am updating Chrome Remote Desktop to apply a scale factor when using
curtain mode (i.e. a loopback RDP session) and I've found that while
the changes are applied and the desktop is scaled, DXGI stops
producing frames.
This is essentially the same issue as crbug.com/1307357 except this
issue is occurring when the DPI is changed rather than the desktop
size.
The fix is to look at the effective DPI for the source being
captured (or the primary monitor when capturing the full desktop)
and then signaling an environment change when the DPI differs.
Bug: webrtc:14894,b:154733991
Change-Id: Id768d4a384434ba59e7396bc919d0ba30d0f6acc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292791
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#39305}
If we are notified of the destruction of the window before a
CaptureFrame call can fail, then we may end up attempting to destroy the
underlying WGC object inside it's own event handler. This can be
problematic, as the class itself may want to run other code. Instead,
we just unsubscribe and signal that any future CaptureFrame calls should
reject.
This also removes setting "is_capture_started_=false" in the item closed
handler, as all that served to do is cause the WgcCapturerWin code to
attempt to restart the capturer, and somewhat muddies up our metrics.
Bug: chromium:1413005
Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39275}
This records high level errors, or success, encountered across the entire capture flow in the DXGI based capturer.
Using the same style as for WebRTC.DesktopCapture.Win.WgcCapturerResult
Bug: chromium:1400204
Change-Id: I7096d1790d7c2a23bbe29761b7dbf40426ce1e6a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291707
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39259}
The mouse_cursor_monitor_unittest.cc was disabled on all platforms, so
it can be deleted.
Bug: webrtc:3408
Change-Id: I294bc502993a5b0a369a60a751c72f72ec909dfc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291724
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39239}
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 is used by CRD and export is required for component builds
to work properly.
Bug: chromium:1291247
Change-Id: I281e490b7d00cbd074b96eac905976af38400f8b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291200
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Salman Malik <salmanmalik@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39143}
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}
1. Use ComponentContext::Create instead of
ComponentContext::CreateAndServeOutgoingDirectory. We're not
actually serving an outgoing directory here, and trying to causes
conflicts when this code is linked into a Fuchsia component.
2. Mark the whole screen as having been updated on each frame. Some
codecs were assuming that nothing on the screen was changing, and
so only the first frame would be shared.
Change-Id: Icb02a2cc097947b85cceddec49291e666257ed81
Bug: webrtc:14681
Bug: webrtc:14682
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283920
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Sarah Pham <smpham@google.com>
Commit-Queue: Hunter Freyer <hjfreyer@google.com>
Cr-Commit-Position: refs/heads/main@{#38682}
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}
The display_id field will be used in
https://chromium-review.googlesource.com/c/chromium/src/+/4020313.
Bug: chromium:1358949
Change-Id: I57b445e0a0fca540a2f3a5941238aee2cd995005
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282960
Reviewed-by: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Tony Herre <herre@google.com>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Simon Hangl <simonha@google.com>
Cr-Commit-Position: refs/heads/main@{#38617}
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}
