Alex Cooper 56b836d958 Ensure there is a unique FrameQueue for each DxgiOutputDuplicator
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}
2022-03-22 16:53:53 +00:00
2021-11-03 14:59:46 +00:00
2022-02-16 12:37:35 +00:00
2021-01-20 15:01:07 +00:00
2022-02-20 14:22:13 +00:00
2021-12-08 08:53:00 +00:00
2022-03-21 06:30:32 +00:00
2020-07-13 11:42:07 +00:00
2021-08-23 13:37:55 +00:00
2021-12-16 17:45:31 +00:00

WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.

The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.

Development

See here for instructions on how to get started developing with the native code.

Authoritative list of directories that contain the native API header files.

More info

Description
No description provided
Readme 255 MiB
Languages
C++ 88.6%
C 3.3%
Java 3%
Objective-C++ 1.9%
Python 1.9%
Other 1%