| Summary: | Jerky video playback of 60FPS video on 120Hz monitor | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Michael Marley <michael> |
| Component: | performance | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | michael, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 6.5.91 | ||
| Target Milestone: | --- | ||
| Platform: | Kubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Michael Marley
2026-02-16 02:14:40 UTC
On my laptop I see some individual frame drops from time to time with the Vulkan decoder, but it uses the CPU quite heavily (maybe Mesa isn't set up to support the codec or something), so it's not particularly surprising to me.
VLC (apart from not playing back HDR videos correctly) seems to be fine though.
How did you determine it drops to 30FPS? Just based on visuals, or also measurements of some sort?
If you run mpv with mangohud, do you see the frame drops in the frame time graph?
> While reproducing the problem, mpv does not report any frame drops.
Maybe the frames are presented at the wrong time, rather than dropped. Like 12--34--56--78-- instead of 1-2-3-4-5-6-7-8-. Or something more chaotic... It's possible that mpv doesn't handle a lack of commit-timing support well, and this will be gone once it's implemented in Plasma 6.7.
(In reply to Zamundaaa from comment #1) > On my laptop I see some individual frame drops from time to time with the > Vulkan decoder, but it uses the CPU quite heavily (maybe Mesa isn't set up > to support the codec or something), so it's not particularly surprising to > me. > VLC (apart from not playing back HDR videos correctly) seems to be fine > though. I checked both the CPU and GPU usage while this was happening and there was no indication that the system wasn't powerful enough to play the video smoothly. > How did you determine it drops to 30FPS? Just based on visuals, or also > measurements of some sort? > If you run mpv with mangohud, do you see the frame drops in the frame time > graph? Just based on visuals. I ran it with mangohud and it showed a nearly-flat green line for the entire video (while the problem was definitely being reproduced) with a CPU usage of <5% and a GPU usage of ~40%, so it doesn't seem to be showing any frame drops if I am understanding the graph correctly. I also tried it with Vulkan/VAAPI and OpenGL/VAAPI. The line was still green and flat for both of those and the problem still occurred (except for OpenGL/VAAPI fullscreen with VRR). > > While reproducing the problem, mpv does not report any frame drops. > Maybe the frames are presented at the wrong time, rather than dropped. Like > 12--34--56--78-- instead of 1-2-3-4-5-6-7-8-. Or something more chaotic... > It's possible that mpv doesn't handle a lack of commit-timing support well, > and this will be gone once it's implemented in Plasma 6.7. That sounds promising. It isn't 12--34--56--78--, but it feels like some more chaotic form of frames being displayed at the wrong times and/or for the wrong amount of time sounds right. The commit-timing thing sounds right as the mpv people specifically requested I try a compositor with wp_commit_timing support. I'm very happy to hear that this extension will be supported in 6.7. I will anxiously await that. Alright, then let's mark it as a duplicate of bug 513283 for now. If commit timing doesn't fix it for you, then you can just re-open this again. *** This bug has been marked as a duplicate of bug 513283 *** |