Ah, you’re probably on Debian 11? That would explain it, because I just noticed that before Debian 12 they used to build mpv without the zimg library for scaling, and --profile=sw-fast seems to make a bigger difference without it.
i7-1260P, so 12 physical cores and I’m not using SMT, but Turbo is on, though the cores do scale very well (using hwp). I noticed early on that having only 1 or 2 cores for a VM would lead to the laptop running hot and the fans being loud quite often, presumably because those cores then go to P1 and switch Turbo on; so I usually give 6-8 cores to each VM, with one exception being in case of video playback, where I make it 12.
Edit: ok wow so mpv even without the two aforementioned options is already 20% lower in CPU usage than totem and with the two options it’s a whopping 4 times better! (uses 4-5 times less CPU as per qubes widget)
And all without any noticeable drop in quality, though this was only a quick test with one HD video.
Is there a way to pass parameters via qvm-open-in-dvm so that when I play a video in a disposable and have mpv set as mime-default there it will use the two parameters automatically?
Edit2: never mind, I just added the params to the desktop file in the template and for some reason it performs even better now in a second test (5-7 times less CPU!!!). Awesome.
It is a shame, that Qubes OS provides default templates with some mediocre players that are several times slower than mpv/mplayer/smplayer, that is crucial in Qubes OS with no hardware acceleration.
And 99% of Qubes OS users have garbage video experience out of the box, maybe even losing interest in Qubes OS as it looks like it is not able to play 1080p on their PC.
It is a shame, that Qubes OS provides default templates with some mediocre players that are several times slower than mpv/mplayer/smplayer, that is crucial in Qubes OS with no hardware acceleration.
(Part of) the reason may be the fact that mplayer and smplayer are not on default template’s (Fedora’s) default repos. mpv is though, so I don’t know.
Of course it is. Nonetheless, something should be done about it. Because these mediocre out of box players do work good enough on GNU/Linux, so it is much more drastic problem for Qubes OS.
I did not submit enhancement issue on the tracker about that, if I recall correctly, because the team is overwhelmed with other things. Maybe it should be done, though, to be useful in the future.
I am personally waiting more for my qubes completion contribution being reviewed and possibly added to the system upstream.
I still would recommend smplayer (it will automatically install mpv backend). Because it has GUI including buttons for average users and more functions for advanced users. Also FLOSS and also available in fedora fusion repos.
Can you really confirm that playing this video in 1080p (e.g. downloaded with yt-dlp), after 0m20s you see absolutely-NOT-jumpy panning?
Sounds hard to believe, can it be that you simply do not expect too high smoothness in the first place and consider “a bit jumpy” as “flawless”?
That’s kind of extreme test. The city panning part is jumpy in full screen (but still watchable). Almost flawless with window sized to 1/4 of the screen area. However, I don’t think one would watch such scenes on a regular basis, e.g. in a movie. If one does, the main issue will be visual hypnosis