tree 3e20c6ca093681064d2d20bc4245f6c4984244a4
parent bf216a7d3e54bc61921ac39fb8a19d65b21c7515
author Salman <salmanmalik@chromium.org> 1674860315 +0000
committer WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> 1674877066 +0000

base_capturer_pipewire: Send frames via callback

Earlier, we were relying on CRD to periodically do frame captures.
This is however not needed since Wayland captures are event based
and once the compositor has send the event/frame to us, we can just
handover the frame to a registered callback. This ensures that we
have a single frame clock that (i.e. one present in the compositor).

Without this change, there is a chance that CRD capture clock is run
out of sync with the compositor's clock and cause unnecessary frame
delays.

See the following ideal scenario, for example, where '+' indicates
when a frame is sent by the compositor and when CRD tries to capture
it. This assumes that the same clock cycle for both CRD and the
compositor, each cycle length is enclosed within | .... |).

Compositor Frame Ready | +... | | +... |
     CRD Frame Capture | .+.. | | .+.. |

In this case, when both the clocks are in sync, CRD is able to
capture frame right after it is generated by the compositor. But if
they are completely out of sync, then CRD can always see a stale
frame (delayed by one cycle and it can cause users to feel stutter).

Compositor Frame Ready | .+.. | | .+.. |
     CRD Frame Capture | +... | | +... |

This stutter can become worse if the compositor is delayed in
generating the frames for some reason (e.g. load on the system).

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