commit b2ab0d7d044d6d0f8b6d00f572341beb28ec954b
author Salman Malik <salmanmalik@chromium.org> Mon Oct 10 18:13:02 2022
committer WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> Mon Oct 10 19:14:20 2022
tree d8928af1576bce1f28ae1f0ae6668970a9cdcee2
parent 8d92c04a6d948f7fe3624d6ad8875d7b9c55ada4

shared_screencast_stream: Allow overwriting next shared frame

This makes the implementation in line with the existing X11
implementation:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/desktop_capture/linux/x11/screen_capturer_x11.cc;l=240-243

The issue I am observing on slightly slower machines with 4k monitor
is that the frames tend to go back in time. I believe this happens
when the shared frame queue is full and has its frame shared. When
that happens, we still end up calling MoveToNextFrame and doing so
we will wrap around the queue and if the capturer captures a frame
again, it sees an older frame. This is causing screen glitches.

This CL normalizes the implementation with X11 (which is known to
work fine) and moves to next frame and always uses it. This helps
to keep the current_frame_ in sync for the caller / capturer and
the capturer will then always see the video moving forward.

On the same machine, these screencasts were taken:
Without this fix: https://youtu.be/7Toi8dL5eYw
With this fix: https://youtu.be/LOE8Si5iOuQ

Bug: chromium:1291247
Change-Id: I51d3d700d3417d31371b12a94f445fc7b530cf73
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278700
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38342}