56b836d9581837ff146257d7b2453169b99db117

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}
…
…
…
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
- Official web site: http://www.webrtc.org
- Master source code repo: https://webrtc.googlesource.com/src
- Samples and reference apps: https://github.com/webrtc
- Mailing list: http://groups.google.com/group/discuss-webrtc
- Continuous build: https://ci.chromium.org/p/webrtc/g/ci/console
- Coding style guide
- Code of conduct
- Reporting bugs
- Documentation
Description
Languages
C++
88.6%
C
3.3%
Java
3%
Objective-C++
1.9%
Python
1.9%
Other
1%