[Spice-devel] Stuttering video playback on LAN

Felix Leimbach felix.leimbach at gmail.com
Sat May 16 16:07:03 UTC 2020


Hi Ferdiano


> > 
> > Hi,
> > 
> > I experience stuttering video playback in remote-viewer despite connecting
> > via GBit/s LAN, using fast hardware and the QXL driver.
> > Up until a video size of roughly 800x600 the playback is smooth. But on
> > anything bigger, like my native resolution of 2540x1440, video playback is
> > stuttering annoyingly.
> > After lots of unsuccessful tinkering with spice parameters and qxl parameters
> > I'm asking you guys for help.
> > 
> > Client:
> > Windows 10 1909
> > Remote Viewer 8.0-256
> > Quadcore i7-7820HQ 2.9GHz
> > 16GB DDR4 RAM
> > 
> > Host of the VM:
> > Gentoo Linux
> > Kernel 4.14.172
> > Qemu 4.2.0

I've updated to newer versions in the meantime, but no noticeable changes.

Qemu 5.0.0
Host kernel 5.4.39
Remote Viewer 9.0-256 (x64) on the Windows 10 Client

> > Quadcore i7-7700K 4.2GHz
> > 64GB DDR4 RAM
> > Server is headless, has no dedicated graphics card, only the Intel HD 630
> > from the CPU
> > 
> > Guest VM:
> > Debian Bullseye
> > I don't think it's guest related, because the same problem happens with a
> > Windows 10 Guest with latest QXL drivers and spice-tools installed.
> > 
> > Network performance client<=>host:
> > Ping 0.2ms
> > Throughput benchmarked at 960MBit/s
> > 
> > Qemu invocation on host:
> > #qemu-system-x86_64
> > -spice port=5906,addr=10.42.2.250,password=changed
> > -vga none -device
> > qxl-vga,ram_size_mb=128,vgamem_mb=32,vram_size_mb=128,vram64_size_mb=256,max_outputs=1
> > -M q35 -smp 2 -cpu host --enable-kvm
> > -drive file=vmfllin.raw,if=virtio,format=raw,index=0,cache=none,aio=native -m
> > 24576
> > -net nic,model=virtio,macaddr=52:54:00:74:01:06 -net
> > tap,ifname=vmfllin,script=no,downscript=no -k de
> > -monitor tcp:127.0.0.1:5956,server,nowait
> > -device virtio-serial,id=virtio-serial1
> > -chardev spicevmc,id=vdagent,debug=0,name=vdagent
> > -device
> > virtserialport,bus=virtio-serial1.0,chardev=vdagent,name=com.redhat.spice.0
> > -rtc base=utc,clock=host -daemonize --device virtio-balloon -boot c
> > -nodefaults -soundhw hda
> > 
> > Spice parameters I tried:
> > -spice
> > streaming-video=all,image-compression=off,jpeg-wan-compression=never,zlib-glz-wan-compression=never,playback-compression=off
>
> Why playback-compression off ?
> The streaming-video should help quite a lot, at least if you play videos.
> And why image-compression is also off?
>
> Without compression and 1GB/s connection at your resolution you fill all the bandwidth with just 8 frames per second.

I tried both, and turning off compression gave slightly better results. It's not the solution, as you say, because it saturates the GB/s link.

Test #1: streaming-video=all and no other options (ie defaults):
Stuttering is worse
Bandwidth: 105Mbit/s

Test #2: streaming-video=all,image-compression=off,jpeg-wan-compression=never,zlib-glz-wan-compression=never,playback-compression=off
Stuttering is a bit less, but still not usable
Bandwidth: 970MBit/s

The remote-viewer.exe on the client uses exactly 100% of one CPU core, regardless of any setting. Is the client the limiting factor??

I noticed very high CPU usage in the guest during playback, because chrome, vlc, mpv used software h264 decoding.
I fixed this by passing a virtualized instance of the hosts Intel GPU to the guest via GVT-g.

These are the qemu parameters I use for GVT-g:
-spice port=5906,addr=10.42.2.250,password=changed
-vga virtio
-display egl-headless,rendernode=/dev/dri/card0
-device vfio-pci,sysfsdev=/sys/bus/mdev/devices/f14c80d5-9ade-4802-9509-1d877d32d159,display=on,ramfb=on,driver=vfio-pci-nohotplug

Unfortunately video playback is still not smoother. In fact it is about the same smoothness but new visual artefacts in the video make it worse. I think this is due to egl-headless.
For testing/comparison I installed a Windows 10 guest with the same GVT-g GPU and used RDP with h264 activated. Playback was much better and used only about 120MBit/s.

Next I tried using the spice-streaming-agent in the guest to send a h264 encoded picture via spice.
However, the windows build of remote-viewer doesn't seem to support this. The new spice display is created and I see the mouse cursor in it but no picture (just black).

Log from the guest:
felix at idefix:~$ ./spice-streaming-agent -d
spice-streaming-agent[2465]: GOT START_STOP message -- request to START streaming
spice-streaming-agent[2465]: streaming starts now
spice-streaming-agent[2465]: Got device info of 1 devices from the plugin
spice-streaming-agent[2465]:    stream id 0: device address: pci/0000/06.0, device display id: 2
spice-streaming-agent[2465]: got a frame -- size is 321265 (26 ms) (1589641660285 ms from last frame)(1589641660258136 us)
spice-streaming-agent[2465]: wXh 1920X1200  codec=1
spice-streaming-agent[2465]: got a frame -- size is 335175 (87 ms) (87 ms from last frame)(189 us)
spice-streaming-agent[2465]: got a frame -- size is 341098 (133 ms) (133 ms from last frame)(66 us)

Log from remote-viewer.exe on client (Windows):
remote-viewer.exe:1436): GSpice-WARNING **: 16:36:47.347: notify the server that stream 48 does not exist
(remote-viewer.exe:1436): GSpice-CRITICAL **: 16:36:47.348: display_handle_stream_clip: assertion 'st != NULL' failed
(remote-viewer.exe:1436): GSpice-WARNING **: 16:36:47.356: notify the server that stream 41 does not exist
(remote-viewer.exe:1436): GSpice-CRITICAL **: 16:36:47.357: display_handle_stream_clip: assertion 'st != NULL' failed
(remote-viewer.exe:1436): GSpice-WARNING **: 16:36:47.363: notify the server that stream 33 does not exist
(remote-viewer.exe:1436): GSpice-CRITICAL **: 16:36:47.364: display_handle_stream_clip: assertion 'st != NULL' failed
(remote-viewer.exe:1436): GSpice-WARNING **: 16:36:47.366: notify the server that stream 34 does not exist
(remote-viewer.exe:1436): GSpice-CRITICAL **: 16:36:47.367: display_handle_stream_clip: assertion 'st != NULL

If I use remote viewer from a linux client then it does indeed work! Playback is nearly smooth, about the same as with RDP and h264!
So I guess it's a bug in the windows remote-viewer. Seems like it doesn't have gstreamer support, so I'll open a bug report.

Any other ideas what I can try to get good reasonable video playback with good office-work performance?

On a side note: Audio via spice isn't working. I hear a few strange noises and then only silence. So I use pulseaudio transmitting the sound to the client independent of spice.

> > -spice
> > streaming-video=off,image-compression=off,jpeg-wan-compression=never,zlib-glz-wan-compression=never,playback-compression=off
> > 
> > Guest kernel:
> > Linux guest 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64
> > GNU/Linux
> > guest kernel: qxl 0000:00:03.0: remove_conflicting_pci_framebuffers: bar 0:
> > 0xe8000000 -> 0xefffffff
> > guest kernel: qxl 0000:00:03.0: remove_conflicting_pci_framebuffers: bar 1:
> > 0xf0000000 -> 0xf7ffffff
> > guest kernel: qxl 0000:00:03.0: remove_conflicting_pci_framebuffers: bar 2:
> > 0xf8054000 -> 0xf8055fff
> > guest kernel: qxl 0000:00:03.0: remove_conflicting_pci_framebuffers: bar 4:
> > 0xd0000000 -> 0xdfffffff
> > guest kernel: qxl 0000:00:03.0: vgaarb: deactivate vga console
> > guest kernel: [drm] Device Version 0.0
> > guest kernel: [drm] Compression level 0 log level 0
> > guest kernel: [drm] 24574 io pages at offset 0x2000000
> > guest kernel: [drm] 33554432 byte draw area at offset 0x0
> > guest kernel: [drm] RAM header offset: 0x7ffe000
> > guest kernel: [drm] qxl: 32M of VRAM memory size
> > guest kernel: [drm] qxl: 127M of IO pages memory ready (VRAM domain)
> > guest kernel: [drm] qxl: 256M of Surface memory size
> > guest kernel: [drm] slot 0 (main): base 0xe8000000, size 0x07ffe000,
> > gpu_offset 0x20000000000
> > guest kernel: [drm] slot 1 (surfaces): base 0xd0000000, size 0x10000000,
> > gpu_offset 0x30000000000
> > guest kernel: [drm] Initialized qxl 0.1.0 20120117 for 0000:00:03.0 on minor
> > 0
> > guest kernel: fbcon: qxldrmfb (fb0) is primary device
> > guest kernel: qxl 0000:00:03.0: fb0: qxldrmfb frame buffer device
> > 
> > Guest X-Org:
> > X.Org X Server 1.20.8
> > [   205.516] (II) LoadModule: "qxl"
> > [   205.516] (II) Loading /usr/lib/xorg/modules/drivers/qxl_drv.so
> > [   205.518] (II) Module qxl: vendor="X.Org Foundation"
> > [   205.520] (II) qxl: Driver for QXL virtual graphics: QXL 1
> > [   205.525] (II) qxl(0): Creating default Display subsection in Screen
> > section
> > [   205.525] (==) qxl(0): Depth 24, (--) framebuffer bpp 32
> > [   205.525] (==) qxl(0): RGB weight 888
> > [   205.525] (==) qxl(0): Default visual is TrueColor
> > [   205.525] (==) qxl(0): Using gamma correction (1.0, 1.0, 1.0)
> > [   205.525] (II) qxl(0): Deferred Frames: Disabled
> > [   205.525] (II) qxl(0): Offscreen Surfaces: Enabled
> > [   205.525] (II) qxl(0): Image Cache: Enabled
> > [   205.525] (II) qxl(0): Fallback Cache: Enabled
> > [   205.525] (==) qxl(0): DPI set to (96, 96)
> > # glxgears
> > 9709 frames in 5.0 seconds = 1941.675 FPS
> > 11719 frames in 5.0 seconds = 2343.780 FPS
> > 
> > Remote-Viewer console output on Windows client:
> > "C:\Program Files\VirtViewer v8.0-256\bin\remote-viewer.exe"
> > --hotkeys=toggle-fullscreen=shift+f11 spice://10.42.2.250:5906
> > (remote-viewer.exe:16324): GSpice-CRITICAL **: 08:00:32.467:
> > _usbdk_hider_update: assertion 'priv->usbdk_api != NULL' failed
> > (remote-viewer.exe:16324): GSpice-CRITICAL **: 08:00:32.526: file
> > ../../src/usb-device-manager.c: line 1815 (probe_isochronous_endpoint):
> > should not be reached
> > (remote-viewer.exe:16324): Gtk-WARNING **: 08:00:32.950: Theme directory
> > 256x256 at 2/animations of theme hicolor has no size field
> > (remote-viewer.exe:16324): Spice-WARNING **: 08:00:50.804:
> > ../../src/channel-display-gst.c:715:gstvideo_has_codec: No video decoders
> > from GStreamer were found
> > (remote-viewer.exe:16324): GSpice-CRITICAL **: 08:00:50.912:
> > _usbdk_hider_update: assertion 'priv->usbdk_api != NULL' failed
> > (remote-viewer.exe:16324): GSpice-WARNING **: 08:00:50.919: Warning no
> > automount-inhibiting implementation available
> > 
> > Thanks,
> > Felix



More information about the Spice-devel mailing list