Improving video playback speed?

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.

Enjoy, mpv is awesome.

3 Likes

@Bearillo

What is your CPU?

@rustybird

I am on Debian 12 minimal (cloned + mpv installed).

Enjoy, mpv is awesome.

It is! I have enjoyed it on GPU accelerated Linux distros. Now, on Qubes OS too :slight_smile:

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.

Interesting. 2 vcpus work fine on the much weaker CPU here with the mpv settings @rustybird shared.

1 Like

Huh…I guess I gotta give mpv a try then!

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.

1 Like

I recommend using smplayer with mpv backend with x11 output driver selected in its settings for video output.

Also related topic about youtube playback (maybe you find something useful there):

1 Like

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.

2 Likes

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.

Have you tried submitting an issue about that?

2 Likes

Do I correctly recall unman had some multimedia template?

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.

2 Likes

I did not submit enhancement issue on the tracker about that, if I recall correctly, because the team is overwhelmed with other things.

So, we can hopefully help with useful suggestions:

qubes completion

Do you have a forum thread about it?

4 Likes

Yes

1 Like

Summarized setting up mpv as recommended here and also ytfzf in my guide.

Thanks for the tips that lead to it!

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.

1 Like

@rustybird

After upgrading to 4.2 and running the same VM (with up-to-date template), I am getting this:

 mpv video.mp4 
 (+) Video --vid=1 (*) (h264 640x360 29.970fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
[vo/x11] Warning: this legacy VO has bad performance. Consider fixing your graphics drivers, or not forcing the x11 VO.
[W][00055.676183] pw.conf      | [          conf.c:  939 try_load_conf()] can't load config client.conf: No such file or directory
[E][00055.676484] pw.conf      | [          conf.c:  963 pw_conf_load_conf_for_context()] can't load default config client.conf: No such file or directory
AO: [pulse] 44100Hz stereo 2ch float
VO: [x11] 640x360 yuv420p
AV: 00:00:00 / 00:02:15 (0%) A-V: -0.000

and the video does not play at all. I can only scroll back and forth in it with the arrow keys.

Others report they cannot play YouTube videos.

Do you have any idea what is going on?

OK, after wasting several hours on this, the simplest solution turned out to be:

  • Reinstall debian-12-minimal template, thus getting rid of stuff which the upgrade installed in templates (including pipewire)

  • Clone the template to debian-12-player

  • In the clone:

apt-get install --no-install-recommends thunar mpv pulseaudio-qubes
  • Configure mpv in the AppVM based on debian-12-player:
$ cat ~/.config/mpv/mpv.conf 
vo=x11
profile=sw-fast
  • Enjoy again full screen 1080p flawless playback
1 Like

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 :slight_smile:

A recent observation (testing mpv in RAM-based qube, as usual, not with a special video):

vcpus=4 makes the video playback choppy at x1.33 speed
vcpus=2 - smooth playback even at higher speeds

During both tests there are no active CPU loads in other qubes.

The physical CPU cores are 4.

what do you have with 3? Assigning all cores to a single qube is a bad idea, the hypervisor requires some CPU to work