commit | 6ff7713a706e65ff2dfe2b1fe2fbb82558db9cc3 | [log] [tgz] |
---|---|---|
author | Salman <salmanmalik@chromium.org> | Fri Jan 27 22:58:35 2023 |
committer | WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> | Sat Jan 28 03:37:46 2023 |
tree | 3e20c6ca093681064d2d20bc4245f6c4984244a4 | |
parent | bf216a7d3e54bc61921ac39fb8a19d65b21c7515 [diff] |
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}
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.