When refactoring the WGC capture path, the check of a closed source
had been placed at a level where the notification of a closed source
was left without being detected since the error message was never
provided to the main WgcCapturerWin::CaptureFrame() which sends the
error message up to the client.
This trivial change ensures that WgcCapturerWin::CaptureFrame() returns
with DesktopCapturer::Result::ERROR_PERMANENT as soon as
WgcCaptureSession::OnItemClosed() has been triggered and it will
ensure that the WGC capture session stops and that any attached
MediaStreamTrack will signal its onended event as expected.
Bug: chromium:330863510
Change-Id: I57e44df417c33efa0595fc277cac5429cf539b26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344420
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41963}
The code uses IDXGIOutput1::DuplicateOutput for screen capture and
it allows only DXGI_FORMAT_B8G8R8A8_UNORM texture format, which
works on most monitor cases except HDR monitor.
HDR mointor returns type of DXGI_FORMAT_R16G16B16A16_FLOAT.
These two types of DXGI_FORMAT_B8G8R8A8_UNORM and
DXGI_FORMAT_R16G16B16A16_FLOAT are all formats that DuplicateOutput
returns based on Windows OS team.
The fix is to add allowed format of DXGI_FORMAT_R16G16B16A16_FLOAT.
Manually repro the issue and validated the fix.
Bug: chromium:40787684
Change-Id: I0a7be38b14a06261d631d2db172f12725edbbf1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/339621
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41749}
Bug: webrtc:15719
Change-Id: I7daf8ee5b90fbe9f1246f1d99211ffa0d8a19f73
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330780
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41503}
This CL is a follow-up of work done in
https://webrtc-review.googlesource.com/c/src/+/323882 where the goal
was to reduce the amount of FrameDropped error logs in
WebRTC.DesktopCapture.Win.WgcCaptureSessionGetFrameResult.
The previous work avoids FrameDropped logs for a minimized window
being captured with WGC but we still se a large amount of these error
(or rather warning) logs. See [1] which comes from Canary.
This CL does two different things to improve the situation:
1) It adds kFramePoolEmpty to the existing
GetFrameResult::kFrameDropped enum to point out that the warning
comes from the frame pool not being able to return a valid new frame.
It also makes it more clear that it does not cause an outer/final
error as WgcCapturerResult::kFrameDropped. We still keep the inner
GetFrameResult::kFrameDropped but it is only produced when the frame
pool returns NULL and our external queue is empty. Hence, a real
frame-drop error. Note that, it is still easy to provoke
kFramePoolEmpty simply by asking for a high resolution at a high rate.
The example in [2] comes from a 4K screen @30fps. Hence, we have not
fixed anything yet.
2) It also increases the size of the internal frame pool from 1 to 2.
This does lead to an almost zero rate of kFramePoolEmpt
warnings at the expense of a slightly reduced max capture rate. BUT,
with 1 as size, we can "see" a higher max capture rate but it is not
a true rate since it comes with a high rate of kFramePoolEmpty
errors. Hence, we "emulate" a high capture rate by simply feeding
copies of the last frame that we had stored in the external queue.
Using 2 leads to a more "true" rate of what we actually can capture
in terms of *new* frames and also a substantially lower rate of
kFramePoolEmpty.
In addition, with 1 as size, if we ask at a too high rate and provide
a copy of the last frame, our CPU adaptation will not reduce its rate
since we think that things are OK when it is actually not.
Also, the samples in [3] and [4] both use 2 as numberOfBuffers
as well.
Let me also mention that with this small change, I a have not been
able to provoke any kFramePoolEmpty error messages.
Finally, geDisplayMedia can be called called with constraints where
min and max framerate is defined. The mechanism which maintains the
min rate is implemented via the RequestRefreshFrame API and it can
be sent to the source (DesktopCaptureDevice) back to back with a
previous timer interrupt for a capture request. Without this change,
these RRFs were also a source of a large amount of
kFramePoolEmpty error logs. With 2 buffers instead; this is no
longer the case.
[1] https://screenshot.googleplex.com/7sfv6HdGXLwyxdj
[2] https://paste.googleplex.com/4795680001359872
[3] https://github.com/robmikh/Win32CaptureSample/blob/master/Win32CaptureSample/SimpleCapture.cpp
[4] https://learn.microsoft.com/en-us/windows/uwp/audio-video-camera/screen-capture#add-the-screen-capture-capability
Bug: chromium:1314868
Change-Id: I73b823b31a993fd2cd6e007b212826dfe1a80012
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325521
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41079}
Bug: webrtc:1314868
Change-Id: Ia743d17d61d7d8ffc44030b5691efef1c7ed7991
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324305
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40994}
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}
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}
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}
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}
* 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}
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}
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}
* 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}
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}
This is a follow up to this CL
https://webrtc-review.googlesource.com/c/src/+/269223
which unintentionally prevents the WindowCapturerWinGdi from returning
permanent errors.
Bug: webrtc:14265
Change-Id: I8eb9f8852fb6247a045d32e407ebdd5f45e6aa9d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271880
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37847}
This overload was removed in C++20.
Bug: chromium:1284275
Change-Id: I67a25ae23fa111e4972d1b207f1c078da13d86a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269440
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37630}
Consumers expect the frame to be valid if Result::SUCCESS is delivered.
If the frame is nullptr, we should deliver ERROR_TEMPORARY instead.
Bug: webrtc:14265
Change-Id: If94a3ead38d7657d7b90bbe046256be697312216
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269223
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37590}
This reverts commit dd32562f242b247aed8add4efecaf3e20c623b9a.
Reason for revert: Updated the original change to dynamically load
the CoreMessaging.dll instead of statically linking with the .lib.
Original change's description:
> Revert "Wait for frames to arrive in WgcCapturer instead of returning nothing."
>
> This reverts commit 93bb3051490253d56dc1cdab4701b91138a151c3.
>
> Reason for revert: It breaks a test while rolling into Chromium,
> see https://webrtc-review.googlesource.com/c/src/+/261780/21#message-4a96e33bfb475f19a618be82bbe72951b23085ef for details.
>
> Original change's description:
> > Wait for frames to arrive in WgcCapturer instead of returning nothing.
> >
> > We're seeing a high instance of "first capture failed" in Chromium when
> > using WGC. We can reduce this by waiting for frames to arrive if there
> > are none in the frame pool instead of returning a temporary error.
> >
> > I've set the maximum time to wait for a frame to 50ms. If no frame
> > arrives before 50ms has elapsed, we will return a temporary error.
> > Added a new test, FirstCaptureSucceeds, to verify that this is working
> > as expected.
> >
> > As part of this I updated the name of the `kCreateFreeThreadedFailed`
> > enum value to `kCreateFramePoolFailed`. The value remains the same
> > since they both report failures in frame pool creation.
> >
> > I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
> > store two frames. This should prevent us from having to wait on the
> > event as frequently. This will increase the latency between capture
> > and display, however. High frame rate applications should not be
> > noticeably affected.
> >
> > Additionally, we uncovered a bug in the OS that prevents window capture
> > when there are displays attached, but none of them are active. Added
> > a new check to `IsWgcSupported` to cover this scenario.
> >
> > Finally, some issues with other WGC tests blocked moving the TryBots
> > to a newer version of Windows. This CL fixes those issues and updates
> > the TryBot configuration.
> >
> > bug: chromium:1314868
> > Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
> > Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> > Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> > Commit-Queue: Austin Orion <auorion@microsoft.com>
> > Reviewed-by: Jeremy Leconte <jleconte@google.com>
> > Cr-Commit-Position: refs/heads/main@{#37404}
>
> Change-Id: If237df4826fe20b6fe2ca4b57253623321bf33c5
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267460
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37408}
Change-Id: I6cc2becd9ed363782ab2f326f58d9401bc8fb820
Bug: chromium:1314868
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267902
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#37470}
This reverts commit 93bb3051490253d56dc1cdab4701b91138a151c3.
Reason for revert: It breaks a test while rolling into Chromium,
see https://webrtc-review.googlesource.com/c/src/+/261780/21#message-4a96e33bfb475f19a618be82bbe72951b23085ef for details.
Original change's description:
> Wait for frames to arrive in WgcCapturer instead of returning nothing.
>
> We're seeing a high instance of "first capture failed" in Chromium when
> using WGC. We can reduce this by waiting for frames to arrive if there
> are none in the frame pool instead of returning a temporary error.
>
> I've set the maximum time to wait for a frame to 50ms. If no frame
> arrives before 50ms has elapsed, we will return a temporary error.
> Added a new test, FirstCaptureSucceeds, to verify that this is working
> as expected.
>
> As part of this I updated the name of the `kCreateFreeThreadedFailed`
> enum value to `kCreateFramePoolFailed`. The value remains the same
> since they both report failures in frame pool creation.
>
> I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
> store two frames. This should prevent us from having to wait on the
> event as frequently. This will increase the latency between capture
> and display, however. High frame rate applications should not be
> noticeably affected.
>
> Additionally, we uncovered a bug in the OS that prevents window capture
> when there are displays attached, but none of them are active. Added
> a new check to `IsWgcSupported` to cover this scenario.
>
> Finally, some issues with other WGC tests blocked moving the TryBots
> to a newer version of Windows. This CL fixes those issues and updates
> the TryBot configuration.
>
> bug: chromium:1314868
> Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> Commit-Queue: Austin Orion <auorion@microsoft.com>
> Reviewed-by: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#37404}
Change-Id: If237df4826fe20b6fe2ca4b57253623321bf33c5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267460
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37408}
We're seeing a high instance of "first capture failed" in Chromium when
using WGC. We can reduce this by waiting for frames to arrive if there
are none in the frame pool instead of returning a temporary error.
I've set the maximum time to wait for a frame to 50ms. If no frame
arrives before 50ms has elapsed, we will return a temporary error.
Added a new test, FirstCaptureSucceeds, to verify that this is working
as expected.
As part of this I updated the name of the `kCreateFreeThreadedFailed`
enum value to `kCreateFramePoolFailed`. The value remains the same
since they both report failures in frame pool creation.
I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
store two frames. This should prevent us from having to wait on the
event as frequently. This will increase the latency between capture
and display, however. High frame rate applications should not be
noticeably affected.
Additionally, we uncovered a bug in the OS that prevents window capture
when there are displays attached, but none of them are active. Added
a new check to `IsWgcSupported` to cover this scenario.
Finally, some issues with other WGC tests blocked moving the TryBots
to a newer version of Windows. This CL fixes those issues and updates
the TryBot configuration.
bug: chromium:1314868
Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#37404}
Several tests starting failing when run on trybots on Win10. This CL
fixes several issues that were uncovered.
Issue 1:
Capture failed to start because `get_Size` returned {0, 0}. This is a
known issue in the WGC API that occurs when there are multiple user
sessions on the same machine.
Solution:
Add a `GetSize` method to the `WgcCaptureSource` interface so we can
fallback to other methods if `get_Size` fails.
Issue 2:
The screen capture tests assume there will be displays attached and
fail if there aren't.
Solution:
Always run `IsWgcSupported` for the appropriate capture type.
Issue 3:
ASAN container-overflow in `GetTestWindowIdFromSourceList`
Solution:
Check the validity of the iterator before dereferencing.
Issue 4:
Occasionally, the call to `GetMessage` in the `CloseWindowMidCapture`
test would hang because there were no messages in the queue.
Solution:
Use `PeekMessage` instead which will return if there are no messages.
Bug: webrtc:14002
Change-Id: I69b2f765db87d34a41d6a1796cd5a81f4029be33
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260202
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36802}
https://webrtc-review.googlesource.com/c/src/+/259457 was a
cherry-pick to M102; as such changes were not made there to keep the
merge to just what had already landed. This addresses the issues raised
on that CL.
Bug: chromium:1316478
Change-Id: I94fad0aa6fe9c67aee5a2f2158524d75b51db48e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259660
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36631}
Versions of Windows before Win11 will crash when `CreateForMonitor` is
called, but the system has no attached displays. This can be avoided by
adding a check to ensure at least one display is found before we return
true in `IsMonitorValid`. Previously we would early return `true` if the
"monitor" we were checking was the `kFullDesktopScreenId`.
Bug: chromium:1316478
Change-Id: I2562fe3834db574cf3706ee1d604472ac03f9ff3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258920
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36555}
The Windows 2019 Enterprise SKU is based on RS5 but is missing support
for WGC. This changes adds a function IsWgcSupported which will check
that the API is actually present, which should be more robust than just
performing a version check.
Bug: webrtc:13932
Change-Id: Ib6a2278f316b9b86671df77fd37468c79564d655
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258163
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36506}
DxgiOutputDuplicator objects hold a reference to the last frame that
they succesfully captured by maintaining a reference to the
SharedDesktopFrame that was passed as their target. This is done because
the DirectX capture APIs may fail to provide an update if there has been
no (or no substantial) change since the last capture call was made.
However, the higher levels of this capture stack
(DxgiDuplicatorController and ScreenCapturerWinDirectX), were unaware of
this, and assumed that the caller of CaptureFrame is the only one who
may have held a reference to the frame. Thus, when CaptureFrame is
called, the DirectX screen capturer assumes that the oldest frame in its
queue can be safely reused.
In the steady state, where capture is not being switched between
monitors, this is fine as there are no competing DxgiOutputDuplicators
being run and this assumption mostly holds true (or the frame is being
overwritten only when the DxgiOutputDuplicator is also done holding it).
However, when capture is being rapidly switched between multiple targets
(e.g. to show a preview of each of the available monitors), this can
result in a frame being held by one DxgiOutputDuplicator being passed to
another as a valid target and overwritten. In the common case of only a
single monitor this is essentially the same as steady state capture,
where there are no competing DxgiOutputDuplicator. In the other common
case of two monitors being captured, the fact that the
ScreenCaptureFrameQueue has two frames ends up masking this issue. Since
each monitor is captured in the same order, the same frame ends up
getting passed to each DxgiOutputDuplicator, so no data actually ends
up getting overwritten. In the case of 3 monitors, the 1st and 3rd
monitor end up sharing a frame, which when capture fails on one of them
surfaces as the other monitor being duplicately shown.
This change addresses the issue by ensuring that each screen that the
ScreenCapturerWinDirectX *actually attempts* to capture, gets it's own
FrameQueue, and thus essentially brings us back to the "steady state"
case for each monitor. Note that this does increase memory usage of
capturers that are switched between multiple targets by 2 frames/target
used (and actually attempted to be captured).
Alternatives considered:
DxgiOutputDuplicator makes a copy of the frame, rather than holding
a reference
This was rejected because adding an additional copy for every
capture upon getting a new frame, would expensive and could degrade
performance.
Allow the DxgiOutputDuplicators to "fail" when there has been no update
This would result in either a breaking change to the API for consumers
or would require the ScreenCapturerWinDirectX to track these last
captured frames; which would result in essentially the same approach,
but with less abstraction for re-using the frames.
Bug: chromium:1296228
Change-Id: I5442ec40e9f234046010b562b258db63693ccc6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256043
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36295}
This CL addresses an issue where the desktop appears to freeze after
resizing the desktop in a curtained CRD session when using the DXGI
capturer. This problem does not reproduce when using the GDI capturer
nor does it reproduce when the Windows session is attached to the local
console.
After digging in, it appears that the DXGI DuplicateOutput API stops
providing updated frame data. No errors are returned but yet no data is
produced. The problem is that when in this condition, there isn't a
good way to discern between this problem and a case where the desktop
is actually static.
The DxgiDuplicatorController already contains logic to attempt to
capture a frame prior to returning success after reinitialization. This
logic works fine in the console case and occasionally works in the
detached session case. What I noticed in my reproductions was that DXGI
would produce a few frames before hanging (usually 1-2 but sometimes 3
or 4). My solution is to check the session state and adjust the number
of frames we attempt to capture (I also simplified the wait logic as
there was a bug in the time calc and it seemed more complicated than it
needed to be).
One option considered would be to introduced a new differ class higher
up in the stack which would run the GDI and DXGI capturers in parallel
(instead of in the fallback configuration as they are today) however
that seemed like overkill for this specific issue.
Bug: chromium:1307357
Change-Id: Idba4bb9b2aa7692040344d480be3f0d09b9ce9e9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256214
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@google.com>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#36286}
getDisplayMedia capture the view of the screens and windows
in the capture dialog, but the issue is that captured view
of the Youtube somehow is blank. It repros only in certain
circumstances, for example, Canary channel.
If user reinstall the Canary as fresh new, we observed that
it doesn't repro.
Cause:
We aren't sure what's cause of this one yet.
Solution:
We decided to provide fallback WGC capturer when the main
capturer (GDI) shows blank. WGC could show yellow outline
in prior Win11 OS, but yellow outline looks better than
blank.
The blank detector and fallback capturer are what screen capturer
already supported. So, the solution will follow similar
pattern in the window capturer.
Bug: webrtc:13726
Change-Id: I620c817d259d7bb5c295adab11c4444349ab1c6c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/252625
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36224}
This CL fixes the issue where artifacts appear during capture with WGC
when the capture source is resized. A video of the issue is available
here: https://bugs.chromium.org/p/webrtc/issues/detail?id=9273#c44
The solution is to use CopySubresourceRegion instead of CopyResource to
only copy valid data into our texture. Additionally, we moved the call
to CreateMappedTexture to before the call to CopySubresourceRegion, as
the latter requires both textures to be of the same size.
Bug: webrtc:9273
Change-Id: I114458d95cbf58550ff653a985dd84db4741e0f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/254100
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36163}
This is a safe cleanup change since top-level const applied to
parameters in function declarations (that are not also
definitions) are ignored by the compiler. Hence, such changes do
not change the type of the declared functions and are simply
no-ops.
Bug: webrtc:13610
Change-Id: Ibafb92c45119a6d8bdb6f9109aa8dad6385163a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249086
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Ali Tofigh <alito@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35802}
