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}
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}
This changes add two new options to the DesktopCaptureOptions class so
consumers can opt in to using the WGC capturer. The capturer is still
behind the RTC_ENABLE_WIN_WGC build flag which is off by default, so
these options will have no affect until that flag is enabled.
Bug: webrtc:11760
Change-Id: Ib7166f3bb335f29aeff8cb5d2bebea2c06c14d4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215243
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33837}
This change disables native cursor capture in WgcCapturerWin to better
support the existing idiom of wrapping a capturer in a
DesktopAndCursorComposer. That means we also need to set the top_left
property of output DesktopFrames, so I've also implemented GetTopLeft in
WgcCaptureSource to facilitate this. I've also added a few unit tests
for WgcCaptureSource.
Bug: webrtc:12654
Change-Id: I5c9988a6f8548b584451b073ac29fbb482e09e2e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215102
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33821}
Previously, windows captured by WgcCapturerWin may have been occluded
by other windows with no functionality to bring them to the top of the
z order. This change implements FocusOnSelectedSource for
WgcCapturerWin to afford consumers this functionality, and match the
experience offered by current capturers.
Bug: webrtc:12664
Change-Id: I8bc067ade90fba0be66a9be57d3429ba54ba1ae0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215241
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33809}
To maintain interoperability between different capturer implementations
this change updates WgcScreenSourceEnumerator to return a list of
device indices instead of a list of HMONITORs, and WgcScreenSource to
accept a device index as the input SourceId. WGC still requires an
HMONITOR to create the capture item, so this change also adds a utility
function GetHmonitorFromDeviceIndex to convert them, as well as new
tests to cover these changes.
Bug: webrtc:12663
Change-Id: Ic29faa0f023ebc26b4276cf29ef3d15d976e8615
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214600
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33673}
This change refactors WgcWindowCapturer into WgcCapturerWin, a source
agnostic capturer, and finishes the implementation to enable both window
and screen capture.
This CL depends on another which must complete first:
196622: Add ability to load CreateDirect3DDeviceFromDXGIDevice from
d3d11.dll | https://webrtc-review.googlesource.com/c/src/+/196622
This feature remains off by default behind a build flag, due to it
adding a depency on the Win10 SDK vv10.0.19041 which not all consumers
of WebRTC have upgraded to. A follow up change later will enable the
rtc_enable_win_wgc build flag, but for now it should remain off.
The basic operation of this class is as follows:
Consumers call either WgcCapturerWin::CreateRawWindowCapturer or
CreateRawScreenCapturer to receive a correctly initialized
WgcCapturerWin object suitable for the desired source type.
Callers then indicate via SelectSource and a SourceId the desired
capture target, and the capturer creates an appropriate WgcCaptureSource
for the correct type (window or screen) using the
WgcCaptureSourceFactory supplied at construction.
Next, callers request frames for the currently selected source and the
capturer then creates a WgcCaptureSession and stores it in a map for
more efficient capture of multiple sources.
The WgcCaptureSession is supplied with a GraphicsCaptureItem created by
the WgcCaptureSource. It uses this item to create a
Direct3D11CaptureFramePool and create and start a
GraphicsCaptureSession.
Once started, captured frames will begin to be deposited into the
FramePool. Typically, one would listen for the FrameArrived event and
process the frame then, but due to the synchronous nature of the
DesktopCapturer interface, and to avoid a more complicated multi-
threaded architecture we ignore the FrameArrived event. Instead, we
wait for a request for a frame from the caller, then we check the
FramePool for a frame, and process it on demand.
Processing a frame involves moving the image data from an
ID3D11Texture2D stored in the GPU into a texture that is accessible
from the CPU, and then copying the data into the new WgcDesktopFrame
class. This copy is necessary as otherwise we would need to manage the
lifetimes of the CaptureFrame and ID3D11Texture2D objects, lest the
buffer be invalidated.
Once we've copied the data and returned it to the caller, we can unmap
the texture and exit the scope of the GetFrame method, which will
destruct the CaptureFrame object. At this point, the CaptureSession
will begin capturing a new frame, and will soon deposit it into the
FramePool and we can repeat.
Bug: webrtc:9273
Change-Id: I02263c4fd587df652b04d5267fad8965330d0f5b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/200161
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33083}
