I am looking for the proper “qubes way” to have decent video playback performance inside a qube (DispVM or AppVM). I am aware of the lack of hardware video acceleration in Qubes OS.
What I have tried so far:
mpv
mplayer
vlc
playing a file in browser (Firefox or Tor Browser)
Results (on a 2K screen, tested with a 480p MP4 file, CPU i7-10610U, no external GPU):
mplayer can play the video smoothly, as long as it is not full screen (then video lags after audio). Usually having it cover 1/4 of the screen surface ensures proper playback speed. If I speed it up though (e.g. x1.5 or more), it starts to choke.
mpv - worse
vlc - slightly better performance. Full screen playback is possible at 1x but not really smooth.
browser - best so far. No problem to play full screen at x1.5 speed. It feels awkward to use a browser for this though (and the player is not really full featured).
What is your experience with that?
How do you play HD videos in full screen?
I’m sure you’ve tried this, but just for completeness’ sake: assigning all CPU cores and enough RAM to the VM in which the video is supposed to be played, as well as playing it “locally”, i.e. the video file resides in that VM is going to improve performance. Note that if the number of assigned cores is changed on a running VM the VM needs to be restarted for those changes to take effect.
Personally I’ve had no troubles so far with both YT (if disabling “Ambient Mode” in the player) and local video files using VLC and Totem, but I do notice problems if I don’t assign all cores to the VM and it’s a Full HD high bitrate video.
Good question, I didn’t even know about that warning
For me it definitely improves playback if I assign more cores to the VM and I’ve so far always used disposables for playback (setting the core number higher in the dvm-template beforehand…one could also create a separate dvm-template for that, but I don’t watch videos often).
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.