fix(linux): update PipeWire engine to the two-level Frame enum + SystemTime display_time#183
Open
Tristan-Stoltz-ERC wants to merge 1 commit intoCapSoftware:mainfrom
Conversation
…Time display_time The Frame enum was refactored into a two-level shape (Frame::Audio / Frame::Video(VideoFrame::*)) and the per-format structs' display_time field was changed from u64 to SystemTime, but the Linux PipeWire engine in src/capturer/engine/linux/mod.rs was not updated to match. Result: 8 compile errors on Linux, no crates.io release compiles there. This commit: - Wraps the four emit sites (RGBx / RGB / xBGR / BGRx) in Frame::Video(VideoFrame::...(...)) to match frame::Frame's current two-level shape. - Replaces `display_time: timestamp as u64` with `display_time: SystemTime::now()`, matching what the macOS and Windows engines already do. The raw PipeWire pts from spa_meta_header is monotonic ns since an arbitrary reference, not wall-clock, so it cannot be converted losslessly to SystemTime. Relative frame ordering survives via channel-send order. - Adds SystemTime to the std::time imports and VideoFrame to the crate::frame imports. `cargo check` on Linux (Ubuntu 24, pipewire 1.0, via nix develop) now succeeds — 16 warnings remaining, all pre-existing lifetime- elision nits unrelated to this fix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
Frameenum was refactored into a two-level shape (Frame::Audio(AudioFrame)/Frame::Video(VideoFrame::*)) and the per-format structs'display_timefield was changed fromu64toSystemTime, but the Linux PipeWire engine insrc/capturer/engine/linux/mod.rswas not updated to match.Result: 8 compile errors on Linux;
0.1.0-beta.1on crates.io does not build there, and neither does the currentmain(verified on Ubuntu 24 with pipewire 1.0).fix-windowsaddressed the Windows path but left Linux untouched.Changes
RGBx/RGB/xBGR/BGRx) inFrame::Video(VideoFrame::...(...))to matchframe::Frame's current two-level shape.display_time: timestamp as u64withdisplay_time: SystemTime::now(), matching what the macOS (src/capturer/engine/mac/mod.rs) and Windows (src/capturer/engine/win/mod.rs) engines already do. The raw PipeWireptsfromspa_meta_headeris monotonic ns since an arbitrary reference, not wall-clock — it cannot be converted losslessly toSystemTime. Relative frame ordering survives via channel-send order.SystemTimeto thestd::timeimports andVideoFrameto thecrate::frameimports.Verification
16 warnings remain, all pre-existing lifetime-elision nits unrelated to this PR.
Follow-ups not in this PR
ptsvalue is currently discarded (let _ = timestamp;) since we can't faithfully convert monotonic-ns to wall-clockSystemTime. A follow-up could add amonotonic_time: Option<Duration>sibling field if callers want sub-ms buffer timing on Linux. Left as a separate concern.portal.rsand a few other files are out of scope here but would be an easy clippy pass.Context
Found while integrating scap into xenia-capture, the screen-capture abstraction of the Xenia remote-session stack — we picked scap as our primary cross-platform backend specifically because of your PipeWire-native Wayland path. Thanks for the work on this crate.