HD video in VMs choppy

User Support
1

Hello all! Sorry if this is a dumb question, but is there something I should’ve done while installing/configureting Qubes to have some kind of video decoding acceleration present in VMs?

As of right now, trying to play any kind of video in any kind of VM results for a choppy/laggy playback for me. Low bitrate 1080p/30 youtube/livestream videos are somewhat watchable, but anything more HQ, higher res, 60 fps etc and it just drops a ton of frames and distorts audio. Even the “”“acceptable”"" low bitrate videos put my 8x4.2+ Ghz used-to-be-top-of-the-line i7 at over 90% load for the whole duration of playback (no throttling from what I’ve seen). It still drops around 5% of the frames but feels somewhat “”“smooth enough”"" to watch, at the cost of the rest of the OS being very sluggish to the point of being barely usable (UI especially). The effect is the same no matter the guest os, video player/browser and ram/vcpu settings applied.

On a separate debian installation on this machine I’d get terrible performance with just KVM - visual slideshow and more crackling than the actual sound. I tried all possible gpu backends (to be honest thinking back I might’ve misconfigured QXL) and the only option that gave me comparable to Qubes video playback performance was -vga virtio. I had to add -display gtk,gl=on to achieve like-native video playback (audio was still garbled, but that’s for another topic). I remember on the guest side the video player finding and opening some library it wouldn’t use before, but I have no idea how does it work on the host side (qemu offloading simple math to real gpu vs qemu passing through instructions from guest directly to gpu?) so not sure if it’d be applicable in Qubes at all.

Of course on bare metal it works perfectly.

Main reason I expect some misconfiguration on my side is the lack of complaints about this issue on github and this forum. I’d suspect at least portion of Qubes’ userbase likes to have something playing in the background as I do and I can’t believe they’d all just put up with the choppy video and unresponsive UI.

Gpu is nvidia 10xx driven by nouveau (Version: 1.0.15 Release: 4.fc25). 64 GB of ram. SSD, but tried to play videos from the browser/straight from ram with same performance.

Any suggestions welcome :slight_smile:

2 Likes
2

Sadly smooth video playback is not really a Qubes thing from my experience. Things have gotten much better over the years and I don’t know why but something was clearly improved. Still your processor seems pretty beefy (8 cores right?) so this is suspect.

1 Like
3

I really hope you are wrong about that and somebody else is going to join the discussion any minute now to point out a silly mistake we’d both made in our configuration that results in choppy vid playback :(. I was really excited to finally be able to have my work and entertainment on the same desktop without worrying one would interfere with another…

The cpu is 8 cores indeed. It’s a stupidly overpriced, very capable piece of hardware. Have done some heavy real-time work on it recentlish and really don’t think it’s the source of the problem (or any other hardware component).

2 Likes
4

If I wanted to give you some hope, in your case this could still be somehow a problem with NVidia drivers. In any case 1080/30 has been working quite well for me lately on my very old processor that has less than 8 cores.

1 Like
5

Also how are you playing your videos? In a browser? If so, try downloading them (say, via youtube-dl) and playing them in both vlc and mpv.

1 Like
6

Thanks, all hope is appreciated :).

I have a history of issues with nouveau on this and multiple other machines with very different hardware configs, so I’m hoping it will indeed end up being a culprit. Problem is installing nvidia blobs in dom0 seems to be a challenge in itself. I spend last few days setting up Qubes and would rather not risk ruining it if I didn’t have to.

I’ll wait few more days and look for answers on my own in the meantime, and if nobody offers any more help I will try to free up a hard disk to install another, test Qubes installation just for nvidia drivers. Hopefully somebody more familiar with the rendering chain will step in and stop me if this is guaranteed not to accomplish anything…

Tried all mpv and vlc and firefox with files from different sources. The effect is pretty consistent between them and the choppiness seem to be directly correlated to the bitrate.

One thing I also noticed, the cpu load seems to increase even more as I increase the size of the player window, reaching peaks when window is in full screen. This doesn’t really make the video any choppier but it does make the system even more sluggish. I haven’t tested this extensively. Maybe a scaling bug?

I probably should have mentioned my display is 1440p usually running faster than 60hz.

1 Like
7

There is no hardware decoding inside VMs (no intel quicksync). With that said, 1080p60 H.264 in MPV uses about 1.75x cores (i7-3840QM) for me. Video in a browser is worse.

I’ve found these help alot:

  • Firefox Prefs > Performance > Use hardware acceleration when available = OFF
  • mpv --vo=x11 --profile=sw-fast. You may want to add these options into mpv.conf so all invocations of mpv benefit.
  • avoid browser video by using streamlink --player-passthrough http,hls --player mpv or youtube-dl
2 Likes
8

Thank you very much for your response! I will test those settings tomorrow and report back. Meanwhile if you can be bothered, would you please tell me if:

  • your system is (unusually) sluggish when playing back videos, especially in full screen
  • your mpv player reports any frames dropped (and if so how many)

from what I’m reading intel quicksync is some dedicated video encoding/decoding coprocessor on intel cpus. I’d expect something like that to exist on modern cpus, but I didn’t know it by name. Not the kind of thing I’d expect any hypervisor to expose to a vm (but I did find some threads about people successfully accessing it by passing through their igpus to the guests).

Instead I was thinking (hoping?) that some kind of acceleration could be provided by gpu through dom0’s xorg process (just like I did on debian), since I don’t think it can tell a difference between between local “native” windows and vm windows. I do not know if it’d require any additional software running on the guest’s side though.

This gpu stuff was always beyond me so if I embarrassed myself at any point feel free to point and laugh.

1 Like
9

1080p60 CPU usage is about 125% in the AppVM + 50% in dom0, for a total of 1.75 cores. Since this is on a system with 4 physical cores, it remains responsive, but I do notice the load.

MPV is not dropping frames or dropping very few frames. It seems to drop a frame whenever I bring up the i stats overlay.

3 Likes
10

Thank you for providing this information. It made me go over the exact cpu usage figures again and I noticed the problem is much more serious than I thought at first.

First let me correct one thing, the framerate itself does not seem to have much effect on the smoothness. 24fps or 60 fps it’s all choppy.

Second I only have few vms opened. Moving the mouse over my wallpaper or any dom0 elements makes 1 cpu thread in dom0 reach 100% (according to xentop). Moving the mouse over some other vm’s window makes 1 cpu in dom0 go 100% or close and 1 cpu in the target vm go almost 100% as well. This happens always and not just with videos playing in the background. This might be expected and unrelated behavior, apologies if so.

Third I have screen tearing. I tested videos from different sources earlier, but they all could’ve had some tearing originally and so my brain paid no mind to the fact. Well I tested some content that for sure comes with no tearing and I do see some. A lot actually.

Playing a video in a vm (any player/browser, any os) results in xentop reporting over 200% usage for a small window, and scales up when I’m resizing the window up to 400% usage when in fullscreen (or almost in fullscreen). The choppiness becomes more noticeable when scaling up the window. The tearing becomes more noticeable as well (but that just might be simply because it’s actually visually bigger).

The system is responsive enough to use most of the time, but it it noticeably sluggish. However every once in a while I’ll try to alt-tab and realize UI is virtually hung up. Trying to alt-tab more or using UI in different ways makes the problem even worse. The video keeps playing for a while with usual choppiness but it eventually freezes as well. At this point the only solution becomes to kill the video playing vm if I can wrestle enough control from the UI. Killing the vm almost immediately brings the system back to full operational speed. I noticed this happens especially often if I try to alt-tab quickly after switching to/from fullscreen.

It becomes more and more clear to me this is some syncing bug. In Windows Manager Tweaks I have disabled all shadows, transparency and all other effects just in case. Unchecking “synchronize to vertical blank” results in even more tearing in the video vm plus introduces tearing to dom0 windows. Unchecking "display fullscreen overlay windows directly’ doesn’t seem to change anything, except for maybe making the video very slightly choppier.

Disabling the display compositing does not make the cpu usage go any lower, but it instantly makes the whole os fully responsive and the video looks very smooth, just as it should if not better :slight_smile: Unfortunately the tearing is unbearable (actually it’s barely noticeable most of the time thanks to 144hz, but when there is a lot movement on the screen or the camera starts to pan around it’s unwatchable).

I can believe people here would put up with screen tearing if they had to but I do NOT believe they would do so without at least some complaining. Searching for ‘tearing’ or ‘vsync’ on this forum returns no relevant threads! It must be a bug, I think I’ll prepare the figures and open a github issue when I get more free time.

If anybody reading this has a working, simple vm (something like debian/fedora template with just some media players installed on top) that lets them watch videos in 1080p in fullscreen with no screen tearing at all, PLEASE please reply in this thread for the benefit of my sanity. Thank you!

1 Like
11

Let me quote myself:

Depending on the hardware, GPU passthrough could help.

1 Like
12

Just a data point, and I’m trying things in whonix in particular on this video file: youtube-dl -f 335 'https://www.youtube.com/watch?v=LXb3EKWsInQ'

mpv is dropping a lot of frames and is very choppy. vlc is very smooth on the other hand. Why? No idea.

1 Like
13

You can also try to play with the number of cores for your multimedia qube. By default, it’s only two, I think, and you said you had a lot. I don’t know if video decoding can use multithreading, but you can still try to see what you get. You can set it via qvm-prefs from the command line or in Qube Settings for this specific qube.

1 Like
14

8 cores with no HTT (disabled in Qubes anyway afaik?). I tried assigning 4,6 and 8 vcpus to my media VM and no difference that I noticed.

I’m thinking about installing some extra gpus to power some HVMs, but for watching youtube videos that sounds like a massive overkill… Also forces you to use one media VM at a time and it would not help with tearing if you still want to have everything displayed on one monitor.

Seeing the same behavior, first time I’ve seen vlc perform better than mpv in anything in years. Further suggests to me there is some timing bug higher in the rendering pipeline.

I feel like that’s way too heavy for a simple test, how about youtube-dl -f 299 'https://www.youtube.com/watch?v=cuXsupMuik4' ? Would you be willing to check it and tell me you have any kind of VM OS/media player combo that can render this with zero screen tearing? Word of warning to anybody else reading, I’d welcome any additional reports from anybody with 2 minutes to spare, HOWEVER be aware that this is about graphical glitches that you might experience on daily basis but simply do not notice. It might just so happen you will see something you will never be able to unsee! If you use QubesOS for your everyday consumption of YT and other media you are clicking that link at your own risk :slight_smile:

On a possibly related note, I’ve also noticed the colorful borders used to distinguish VM windows also tear for some reason? I thought those are drawn by the secure window manager in dom0 so I have no idea why would they. “Native” dom0 windows seem to be vsynced or they tear so little I’m not able to spot it.

I really hope there is a way to get some kind of vsync for VM windows. I’ll take a look at dummyqbs_drv when I have some spare time, I wonder if some kind of triple buffer could be implemented safely.

EDIT: I’m asking about tearing even though the original topic was about choppiness/stuttering because those can be close correlated sometimes. For example the smoothness of VLC could be just an illusion resulting from the video output getting teared multiple times in the rendering pipeline (or whatever the proper name is). Ideally I’d like at least one VM vsynced to dom0’s xorg so I can compare different software and configs to achieve the smoothest possible playback - even if the vsync can only be achieved temporarily (because of security concerns or whatever)!

15

Hi, but I encountered choppy streaming video played in Firefox in a standard Fedora 32 VM. (Qubes R4.1, 2 vcpu). When I installed debian-10-minimal template and installed Firefox along with qubes-core-agent-networking (because I didn’t get internet access in a DispVM based on this template at first, I wondered if I could solve the problem by installing it), I used the DispVM and streaming video was quite fluent (although had very high CPU usage, which was identical to previous Fedora VM), no matter how many vcpu I assigned to it (2, 4, 6).

1 Like
16

Generally, if I want to watch a full-screen movie in Qubes 4.0 (especially with friends/family*), I will do one or more of the following:

  1. Shut down all unnecessary VMs.
  2. If inconvenient to shut down (e.g. work in progress), suspend any cpu-intensive processes (e.g. Firefox) in remaining VMs using ctrl-z or other methods.
  3. If video is to be played via browser, close all other browser tabs in that session. However mpv is usually a better bet.

This is on Sandy-bridge (2011 CPU) quad-core (with HT disabled). Screen size is 1920x1080 on integrated GPU.

Now this isn’t always necessary (variables include how many browsers, how many tabs and which sites are open).

This is generally not choppy. I do not recall if there are non-default modifications of xfce/compositor settings.

B

* and temporarily disable the screen-saver in this case, as it is not movie-aware!

17

I started using Qubes just recently and found choppy video in Firefox from certain sites while using the default Fedora AppVMs. When I switched to Firefox in Debian AppVMs, they render just fine. I don’t know what causes this, but it made me switch mostly to Debian.

18

Newer firefox made webrender mandatory, and software webrender in VMs performs really bad for me.

debian-stable was stuck on firefox-esr-78 for a while which had the old, fast rendering, that might explain why debian firefox was a better experience than fedora firefox.

Workarounds: Make an online movie [in browser] to play correctly - #2 by airelemental

Related bug: 1738247 - Videos stutter with Webrender Software on a Xen VM with no hardware acceleration compared to Firefox 78 esr

2 Likes
19

I’m using Firefox 95 on both Debian and Fedora, so I think my comparison is at least somewhat valid (maybe). While viewing the same videos from the same website, it is jumpy on Fedora but smooth on Debian. I’m sure your info about Firefox ESR being better is this regard is true, and that Mozilla bug report is interesting regardless.

2 Likes