Web browser's (Firefox) video playback is laggy

User Support General
1

Web browser’s (Firefox) video playback is laggy

4 Likes
2
2 Likes
3

You probably run software renderer, you need to set up either an accelerated vm or seamless GPU passthrough

Or your connection is bad

Or you’re swapping

Or something else, you have registered on this forum a year ago, who knows what you’re running now lol

1 Like
4

Or you have “theater mode” enabled …

Or you’re trying 8k …

2 Likes
5

@OvalZero What’s unclear about the question? Obviously Firefox in a default App qube doesn’t play videos smoothly. I have the same problem on my Librem 15. Full HD quality. Adding more CPU cores to the VM can help.

1 Like
6

Video playback generally seems fine for me with Firefox so I think it is completely acceptable to ask for more detail from the OP. This includes 1080p playback. I only run into significant performance issues if I switch to 1440.

It does stutter on occasion but most of the time that seems to be due to me running other CPU intensive activity in other qubes.

Edit to add: I have frequently been playing fullscreen, 1080p content from Firefox. I’ve watched several full length movies just this weekend, although those were PiP on a 2k monitor (not fullscreen) and varied in streaming quality from 720 to 1080. These played fine for nearly all, if not all, of the content. I do not have a dedicated GPU. Just a several year old CPU (i7-10710U) .

1 Like
7

I finally gave up using Firefox. My CPU usage has shot up from about 20-30% to 50-80%. CPU temp also increased +10C. I’ve also evolved over the year from 4000MiB to 10240MiB for smoother performance. This is on a minimal template. It’s mainly just for browsing or news and the most intensive website is msn.com.

I tried Opera this past week and CPU usage is usually around 5%-10% and my CPU temp is 10C lower. I have it setup with essentially every junk turned off. The performance also seems smoother. I use Mullvad or Tor for more privacy.

1 Like
8
9

What question? It’s more of a vague description. At best.

I think it’s always better to explain

  • what you want to achieve exactly,
  • what you’ve done so far,
  • and exactly what happened and
  • under what circumstances including hardware description, system specs like kernel versions, program versions, drivers loaded, plugins installed, config etc.
1 Like
10

I don’t use firefox anymore in general (I prefer Mullvad, Librewolf, tor, ungoogled-chromium and Brave)
Brave is a very good choice to run youtube, video…

11

Hello, my little security lovers.

This thread seems to be turning into a mutual exchange of “works for me”, “doesn’t work for me”. This is not the approach I would like to see in the Qubes OS community.

I encountered the same problem, switching to Chrome did not help much. Those who encounter the same problem can conduct several experiments, if you have the same result as me, then the cause of the problem is listed below.

  1. Open any YouTube video in full screen. The quality does not matter, 360p is fine, regardless of your monitor.

  2. If you see lags, start reducing the browser window (and accordingly the video)

  3. When I reach 1/4 of the 4K monitor, I achieve normal playback quality.

If you have the same problem, then you most likely have a very good monitor, but in the context of Qubes OS this is rather bad. To transmit frames, Qubes OS uses vchan in dom0 (or sys-gui), frames are transmitted in RAW format, as a result, tens of GB of frames are sent per second through a very slow vchan, completely uncompressed. This is a huge drawback of the current Qubes OS gui in my opinion. GPU passthrough will not help here in any way, this is a fundamental problem of the Qubes OS and vchan architecture. This problem also prevents the use of gaming HVM. If the game is full screen, 20 Fps is the limit of Qubes OS capabilities. This is not enough for most GPU games

You can reduce the screen resolution to HD / FullHD. But of course, on a good monitor this will lead to a deterioration in quality, but the frame size will become smaller and the vchan buffer will not overflow. The monitor size must be changed in the dom0 settings

According to personal experiments, if you install the vnc client in dom0, and the server in DomU with video, there will be no such lags, but frames are lost, since vchan is not able to effectively transmit even frames compressed for the vnc protocol.

Potential solutions are simple:

  1. Xpra, check if it works.
    Pros:
    . checked if it works on pvh Qubes
    . Provides very high-quality video stream compression using frame deltas, H265/265/Av1/vp9 encoding
    . In theory, it should allow transmitting about 100 FPS in 4K

Cons:
. I couldn’t get it to work if DomU is in HVM mode.
. Requires two hardware video decoders. The first encoder should be in DomU, encodes video, sends it to dom0, and the decoder in dom0 should show the video stream. Requires two video cards, in fact. It is acceptable if one is built into amdcpu. I don’t know if there is such a thing in Intel cpu
. Tcp connection between potentially malicious DomU and dom0 can have a catastrophic impact on security

  1. Moonlight
    . Not suitable for Qubes OS, requires udp between cube and dom0, Qubes OS does not support udp

  2. VNC
    It’s just inconvenient, instead of lags there is a loss of frames

  3. Shm/Shared framebuffer
    Pros
    . Should give fps close to ideal

Cons
. Shared video buffer between dom0-DomU, security suffers
. It is necessary to somehow use one video card simultaneously in dom0 and DomU
. It is hardly possible at all within Qubes OS

If anyone has a similar experience or possible solutions to the problem, I would be very glad to know about them and finally get rid of the need for dualboot with Windows.

12

Interesting. I did not know about vchan. Searching it for glimpse (https://mirage.io/blog/introducing-vchan, https://opam.ocaml.org/packages/vchan/), it seems the usage is very specific to Qubes (or Xen).

Is vchan then a software implementation? What makes it so slow? I’m curious whether a powerful GPU in dom0 (not dGPU) could solve the laggy display problem. Because usually in other OSes, even weak iGPUs are enough for at least “displaying” contents to a monitor.

13

Try simple window resize test.
GPU is in dom0
Resizing window in dom0 is instantenous, but in domU you see redrawings.

14

I have never seen anyone complaining with the issue while using Brave browser.

15

I will try to explain it as simply as possible: the bottleneck is the transfer of frames between VMs, vchan is single-threaded and slow, all cubes use it to transfer data to sys-gui. Frames are transferred in raw form, RAW, that is, each frame is transferred entirely and without compression. The higher the frame resolution, the larger the size, on a FullHD screen this can lead to the transfer of hundreds of gigabytes per second, xen/vchan buffers are not able to transfer so much per second, the buffer overflows and the necessary frames simply do not reach dom0. This cannot be fixed by changing the browser to brave or something else, the browser has nothing to do with it, this is precisely the bottleneck of XEN. GPU in dom0 will not help either, frames are already transferred in RAW format, there are no difficulties with their decoding. The fix will require either replacing the user’s monitor with one with a low resolution, or a fundamental change to the Qubes gui subsystem. I don’t know of a simple solution to this problem, it requires the involvement and commitment of the Qubes OS developers to implement it in at least a relatively secure way.

P.s. increasing vchan buffers will also not solve the problem, since it will not increase the speed in any way, a buffer of any size will overflow after a few seconds, since its filling will be faster than clearing