commit | dd32562f242b247aed8add4efecaf3e20c623b9a | [log] [tgz] |
---|---|---|
author | Mirko Bonadei <mbonadei@webrtc.org> | Sat Jul 02 07:40:08 2022 |
committer | WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> | Sat Jul 02 07:41:21 2022 |
tree | ae5f117228e1589e5679e6b71315d72911f756b7 | |
parent | a05e955d17705b25691ef6cfc081f2e2ce921e4b [diff] |
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}
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.
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.