Created attachment 195048 [details] hack patch DESCRIPTION When I record my 120Hz display with OBS at 60 FPS using PipeWire, the capture doesn't appear to sample frames evenly; instead it looks stuttery. I did some digging, and I think it could be caused by the fact that https://invent.kde.org/plasma/kwin/-/blob/6c523e20d1280b397d2437246ee86649fd8b0bbb/src/plugins/screencast/screencaststream.cpp#L529 uses whole milliseconds (where 120Hz is ~8.333 ms but it ends up rounding to 8?) which might not be precise enough. Additionally, the deadline appears to be measured from when the previous frame finished being sent rather than a fixed schedule and thus the delay might be adding up constantly. I hacked it so that nanoseconds are used now and a fixed one-interval deadline is applied each time instead of restarting it and capture got a lot better on my setup. I attached that hack to this ticket. STEPS TO REPRODUCE 1. Set your display to 120Hz 2. Run a vsynced client, ideally one that shows a different color/image for odd/even frames (I use this: https://gitlab.com/fililip/vulkan-vsync-tester) and make sure it's stable on the actual display without any frame drops caused by something else 3. Capture the screen at 60 FPS with OBS OBSERVED RESULT There are mistimed frames (colors go crazy) when playing back the recording using mpv and VRR (or when exporting all frames to image files), which means the capture interval somehow always shifts. EXPECTED RESULT All frames are the same in the recording when played back since the app is 120 FPS and the recording is 60 FPS, so either the odd or even field makes up each captured image. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.7.4 KDE Frameworks Version: 6.28.0 Qt Version: 6.11.1 Kernel Version: 7.1.7-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 64 GiB of RAM (62.7 GiB usable) Graphics Processor: AMD Radeon RX 9070
Created attachment 195049 [details] hack patch Whoops, I attached an incomplete diff when cleaning it up (displays with EDIDs advertising ~119.99Hz could get treated as 119Hz displays instead of 120), sorry about that.
The idea seems sane, at worst it will be harmless. Please finish that patch and ideally submit it to invent.kde.org
Created attachment 195076 [details] hack patch for master Here's a better version rebased for the master branch. I'm not sure if more changes aren't necessary and if this is the right approach to fix it in the first place. Window previews appear more stable with this patch for sure, albeit they can occasionally drop a frame or two sometimes, so that could be a hint there are more parts of the code that might need adjustments.
After combining this patch together with the commit-timing-v1 MR it looks like it's basically fixed or at the very least drastically improved compared to before, so the other issue might have simply been less than ideal presentation times. Now even mismatched capture/refresh rates judder evenly in window previews (i.e. the window being on another screen with a different refresh rate) and on recordings.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9736
Git commit 3fad2bbcdcbd087c11a9f3b7848bc2043ccc2341 by fililip s.. Committed on 17/08/2026 at 12:18. Pushed by vladz into branch 'master'. plugins/screencast: make screencasts smoother Instead of using the time a frame finished being sent, use a deadline as a reference for when to schedule screencasts. Additionally, make the relevant calculations use nanoseconds and improve precision for the maxFramerate parameter passed to PipeWire. Doing so improves screen capture frame pacing a lot on my laptop and desktop. M +23 -10 src/plugins/screencast/screencaststream.cpp M +2 -1 src/plugins/screencast/screencaststream.h https://invent.kde.org/plasma/kwin/-/commit/3fad2bbcdcbd087c11a9f3b7848bc2043ccc2341
Just to chime in: I tested the single change (3fad2bbcdcbd087c11a9f3b7848bc2043ccc2341) via manual backport to KWin 6.7 and it greatly improves in-game pacing for Sunshine as well. For previous versions of KWin we worked around the poor pacing by negotiating maxFramerate as variable rate (0, 1), but starting with KWin 6.7, a new issue was introduced in which general pacing (in games, etc.) remains good, but desktop animations run at roughly half-speed when using variable rate capture. Negotiating the actual target framerate via maxFramerate fixes the half-speed animations at the expense of relying on the compositor pacing doing a good job. I didn't get a chance to bisect the specific change that caused the issue, but this improvement would let us eventually move away from variable rate capture in Sunshine in order to resolve the half-speed desktop animations. I've opened a draft PR for Sunshine to be ready for the 6.8 release: https://github.com/LizardByte/Sunshine/pull/5538