Without this change a FrameDropped sample will be added to
WebRTC.DesktopCapture.Win.WgcCaptureSessionGetFrameResult at the
current capture rate as long as a captured window is minimized.
Bug: webrtc:1314868
Change-Id: I9b68675486642e7ca25674df689c207ac94a206e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323882
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40969}
Makes it more clear that a certain API is only supported in Windows 11.
Bug: webrtc:15451
Change-Id: Ic3abfb2cbf0e30f9cb722ac843876f41279bf200
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323161
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40931}
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}
NSApplicationActivateIgnoringOtherApps is about to be deprecated.
The default behavior is good enough.
Tested on Chrome using https://wicg.github.io/conditional-focus/demo/
Bug: webrtc:15511
Change-Id: I1f59aea3d4e7c4942d17ee5c4f1b6c2d398016ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321080
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Auto-Submit: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40795}
This reverts commit 0f87b3853554ee5d4e92e487a5165b57771b6742.
This is not needed with the macOS 14 SDK, which has the fix, and which
was landed in https://crrev.com/c/4875713.
Bug: chromium:1484363, chromium:1431897
Change-Id: I1e019ce71b90333d5d1333a3cf8bb510a3dbd212
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320820
Reviewed-by: Tomas Gunnarsson <tommi@google.com>
Auto-Submit: Avi Drissman <avi@chromium.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40777}
Only has an effect on Windows versions higher than 2104 (10.0.20348.0).
Bug: webrtc:15451
Change-Id: I3ca48c88a6c2b9b87d43805fcb2ade444cd90480
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318060
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40721}
These two functions contain complicated logic that will be used as
a fallback in Chromium if the new macOS picker code does not work
as intended.
Bug: chromium:1478172
Change-Id: I5f2878c5a8da38d59aa42ec1358398e3c921b65c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319260
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40711}
The build target that CreateFromCGImage() belongs to, desktop_capture_obj
is not visible externally. A utility header is created to make it accessible.
Bug: chromium:1471931
Change-Id: Ie40f39114d277dc4b62fe2ce95a6b0c7b61a3943
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318123
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Johannes Kron <kron@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40659}
CreateFromCGImage() is needed to be called directly when we move away
from using the deprecated API that is used in CreateForWindow().
Bug: chromium:1471931
Change-Id: I28a2972a2a995103829fd9aff4bc1137a8b424b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/315324
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40563}
This reverts commit 726992d7a4722b8a283d797d04432d0c6335ca96.
Reason for revert: Relanding with original errors fixed (tested by building the patch locally against Chromium)
This change no longer attempts to migrate the display size protocol from fuchsia.ui.scenic.Scenic/GetDisplayInfo to fuchsia.ui.display.singleton.Info/GetMetrics because the latter API was introduced in Fuchsia API 12, which is not yet supported in Chrome (hence some of the build errors causing the revert).
Original change's description:
> Revert "[fuchsia] remove Scenic and GFX dependencies in DesktopCapturer"
>
> This reverts commit fe5be2eb4ff8dccd96257fb8cbf32500c636c358.
>
> Reason for revert: This breaks the WebRTC roll into Chromium:
>
> - https://chromium-review.googlesource.com/c/chromium/src/+/4688561
> - https://ci.chromium.org/ui/p/chromium/builders/try/fuchsia-binary-size/399140/overview
>
> Error:
>
> [4273/4389] CXX obj/third_party/webrtc/modules/desktop_capture/desktop_capture/screen_capturer_fuchsia.o
> FAILED: obj/third_party/webrtc/modules/desktop_capture/desktop_capture/screen_capturer_fuchsia.o
> ../../buildtools/reclient/rewrapper -cfg=../../buildtools/reclient_cfgs/chromium-browser-clang/rewra...(too long)
> ../../third_party/webrtc/modules/desktop_capture/screen_capturer_fuchsia.cc:59:10: error: use of undeclared identifier 'capturer'
> 59 | return capturer(new ScreenCapturerFuchsia());
> | ^
> ../../third_party/webrtc/modules/desktop_capture/screen_capturer_fuchsia.cc:199:36: error: no type named 'InfoSyncPtr' in namespace 'fuchsia::ui::display::singleton'
>
> Original change's description:
> > [fuchsia] remove Scenic and GFX dependencies in DesktopCapturer
> >
> > We previously used:
> > - fuchsia.ui.scenic.Scenic/UsesFlatland to determine whether to use
> > Flatland; from now on it should always be the case, so this check is
> > no longer necessary.
> > - fuchsia.ui.scenic.Scenic/GetDisplayInfo to get
> > fuchsia.ui.gfx.DisplayInfo. This has been migrated to
> > fuchsia.ui.display.singleton.Info/GetMetrics and
> > fuchsia.ui.display.singleton.Metrics.
> >
> > Bug: fuchsia:100303
> > Change-Id: I147da9ffdf0ca49e1c5bde5d188e434fc660becc
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311860
> > Reviewed-by: Emircan Uysaler <emircan@google.com>
> > Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> > Commit-Queue: Caroline Liu <carolineliu@google.com>
> > Cr-Commit-Position: refs/heads/main@{#40432}
>
> Bug: fuchsia:100303, b/291393959
> Change-Id: Iae70e568a8c9819e40e48069af8cea0d4ef2b6c5
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311801
> Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#40436}
Bug: fuchsia:100303, b/291393959
Change-Id: Icb7074ac86c1804ab2bdf809ea1496539ee2bf80
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312000
Commit-Queue: Caroline Liu <carolineliu@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40452}
This reverts commit fe5be2eb4ff8dccd96257fb8cbf32500c636c358.
Reason for revert: This breaks the WebRTC roll into Chromium:
- https://chromium-review.googlesource.com/c/chromium/src/+/4688561
- https://ci.chromium.org/ui/p/chromium/builders/try/fuchsia-binary-size/399140/overview
Error:
[4273/4389] CXX obj/third_party/webrtc/modules/desktop_capture/desktop_capture/screen_capturer_fuchsia.o
FAILED: obj/third_party/webrtc/modules/desktop_capture/desktop_capture/screen_capturer_fuchsia.o
../../buildtools/reclient/rewrapper -cfg=../../buildtools/reclient_cfgs/chromium-browser-clang/rewra...(too long)
../../third_party/webrtc/modules/desktop_capture/screen_capturer_fuchsia.cc:59:10: error: use of undeclared identifier 'capturer'
59 | return capturer(new ScreenCapturerFuchsia());
| ^
../../third_party/webrtc/modules/desktop_capture/screen_capturer_fuchsia.cc:199:36: error: no type named 'InfoSyncPtr' in namespace 'fuchsia::ui::display::singleton'
Original change's description:
> [fuchsia] remove Scenic and GFX dependencies in DesktopCapturer
>
> We previously used:
> - fuchsia.ui.scenic.Scenic/UsesFlatland to determine whether to use
> Flatland; from now on it should always be the case, so this check is
> no longer necessary.
> - fuchsia.ui.scenic.Scenic/GetDisplayInfo to get
> fuchsia.ui.gfx.DisplayInfo. This has been migrated to
> fuchsia.ui.display.singleton.Info/GetMetrics and
> fuchsia.ui.display.singleton.Metrics.
>
> Bug: fuchsia:100303
> Change-Id: I147da9ffdf0ca49e1c5bde5d188e434fc660becc
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311860
> Reviewed-by: Emircan Uysaler <emircan@google.com>
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Commit-Queue: Caroline Liu <carolineliu@google.com>
> Cr-Commit-Position: refs/heads/main@{#40432}
Bug: fuchsia:100303, b/291393959
Change-Id: Iae70e568a8c9819e40e48069af8cea0d4ef2b6c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311801
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40436}
We previously used:
- fuchsia.ui.scenic.Scenic/UsesFlatland to determine whether to use
Flatland; from now on it should always be the case, so this check is
no longer necessary.
- fuchsia.ui.scenic.Scenic/GetDisplayInfo to get
fuchsia.ui.gfx.DisplayInfo. This has been migrated to
fuchsia.ui.display.singleton.Info/GetMetrics and
fuchsia.ui.display.singleton.Metrics.
Bug: fuchsia:100303
Change-Id: I147da9ffdf0ca49e1c5bde5d188e434fc660becc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311860
Reviewed-by: Emircan Uysaler <emircan@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Caroline Liu <carolineliu@google.com>
Cr-Commit-Position: refs/heads/main@{#40432}
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}
This flag is no longer used in Chrome and can now be removed.
Bug: chromium:1314868
Change-Id: Id91b3352dc7ec0543d54894cc206a6e0c7667e9e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309960
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40337}
This CL allows the users to now enable/disable WGC capturing support
for Window and Screen sharing independently.
Bug: chromium:1314868
Change-Id: Ieeb15539434dac2caf29c515aa7c5dbb7abcc5df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309560
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40330}
This change fixes a minor issue where we previosuly assumed that the
following was true:
RTC_DCHECK_EQ(map_info.RowPitch, current_frame->stride())
It turns out that this is not always the case when sharing a window
where the stride can sometimes be a few bytes smaller than the
rowpitch.
The code is behind a command-line flag and no tests are affected.
Given limited review resources I therefore plan to bypass the CQ.
I know that it is not recommended but the change has been tested
locally on two different Windows platforms and it does avoid an
existing crash.
Code-Review: alcooper@chromium.org
No-Try: true
Bug: chromium:1421242
Change-Id: I01e7105a6f9fca7ce1349a57635dd373c28d160b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309342
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40308}
This CL adds a light-weight detection of "frame content has changed
since last frame" to an existing pass where bytes are copied from a
texture to a DesktopFrame. The resulting boolean can then later be
used to bypass a full detection of if the content is static or not.
As a result, we only check for static content for a small fraction of
all captured WGC frames and this reduces the total load when 0Hz
is enabled for WGC.
Both WGC and 0Hz support for WGC is still behind a flag.
Bug: chromium:1421242
Change-Id: If9e3721c60a244a3919758fe861d56d4b54cb039
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308821
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40299}
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}
