On 5/17/20 6:35 PM, Felix Leimbach wrote:
Hi Uri,
On 17.05.20 16:08, Uri Lublin wrote:
On 5/16/20 7:07 PM, Felix Leimbach wrote:
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
<snipped>
<snipped>
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
Perhaps here it would help to set streaming-video=all -spice option.
It doesn't really help. Still very stuttering playback, even with a video-player window size of only 720x576.
I now believe this is caused by a CPU bottleneck on the CLIENT (not guest), i.e. my Windows 10 machine.
virt-viewer.exe uses consistently 12% CPU, which is 100% of one core (Quad Core with SMT => 8 logical cores).
This is crazy, since the CPU core is running a modern i7 at 3.6 GHz (Turbo) with no other significant CPU users (system is idle).
Could this be a problem of remote-viewer.exe not using gstreamer codecs (and hw accel) properly?
Got these spice-debug messages on the client: "no video decoders from GSTreamer for {mjpeg,vp8,h264,vp9,h265} were found".
Maybe the client is built without gstreamer.
Also I noticed that the qemu process on the host is using much CPU, probably due to spice encoding the video frames.
The host shows 4 qemu-ystem-x86_64 threads using 93%, 34%, 24%, 16% CPU when playing a 720x576 video in the guest.
However the guest shows only 14% and 7% use for its 2 vCPUs in htop because it uses VA-API (GPT-g) in the video player (vlc, mpv).
With egl-headless, spice-server encodes the whole screen, not 720x576
video. Since the client
supports almost no codec likely
it's using mjpeg
So the host qemu threads use MUCH more CPU than the guest. When I disconnect spice (video still playing) the host qemu CPU usage drops to 35%, 1%, 1%, 1%, as expected.
Conclusion: Spice encoding on the host is very CPU hungry.
Your conclusion makes sense to me.
Is it possible to GPU-accelerate the video encoding in the host qemu process?
I think it can not use anything other than mjpeg if that's the only
codec the client supports.
I've built spice and qemu with gstreamer and drm support and VA-API is working nicely.
Can spice use that? How?
Possibly, for H264 you need to change the get_gst_codec_name (gstreamer
pipe);
For vp8 it should be done already.
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).
You may be the first to test spice-streaming-agent + windows client.
I think there is some work to be done in the windows client to make
it handle better streams from spice-streaming-agent
Also there is some work to be done to enable spice-streaming-agent
on windows guests.
Log from the guest:
felix@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
Note that it's not H264, but MJPEG (codec=1)
You are right, so I debugged this:
Launching spice-streaming-agent with GST_DEBUG=6 shows a bunch of h264 related messages which seem to indicate that the gstreamer codecs are loaded (not sure):
gstregistry.c:461:gst_registry_add_plugin:<registry0> adding plugin 0x55d279f8fe70 for filename "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstuvch264.so"
gstregistry.c:577:gst_registry_add_feature:<registry0> adding feature 0x55d279fe1650 (video/x-h264)
gstregistrychunks.c:729:gst_registry_chunks_load_feature: Added feature vp8enc, plugin 0x55d279ed1150 vpx
However I didn't find an argument to force spice-streaming-agent to use a specific codec. Reading the source code I found the option "-c codec_name=h264", but it doesn't seem to have any effect.
Maybe it fails auto-negotiation with the client which does not support it?
Likely.
Uri.
On the client with the "--spice-debug" option I found interesting messages:
(remote-viewer.exe:15956): Spice-DEBUG: 17:17:06.218: ../src/channel-display-gst.c:792:gstvideo_has_codec: No video decoders from GStreamer for mjpeg were found
(remote-viewer.exe:15956): GSpice-DEBUG: 17:17:06.218: ../src/channel-display.c:894 GStreamer does not support the mjpeg codec
(remote-viewer.exe:15956): Spice-DEBUG: 17:17:06.219: ../src/channel-display-gst.c:792:gstvideo_has_codec: No video decoders from GStreamer for vp8 were found
(remote-viewer.exe:15956): GSpice-DEBUG: 17:17:06.220: ../src/channel-display.c:894 GStreamer does not support the vp8 codec
(remote-viewer.exe:15956): Spice-DEBUG: 17:17:06.221: ../src/channel-display-gst.c:792:gstvideo_has_codec: No video decoders from GStreamer for h264 were found
(remote-viewer.exe:15956): GSpice-DEBUG: 17:17:06.222: ../src/channel-display.c:894 GStreamer does not support the h264 codec
(remote-viewer.exe:15956): Spice-DEBUG: 17:17:06.223: ../src/channel-display-gst.c:792:gstvideo_has_codec: No video decoders from GStreamer for vp9 were found
(remote-viewer.exe:15956): GSpice-DEBUG: 17:17:06.224: ../src/channel-display.c:894 GStreamer does not support the vp9 codec
(remote-viewer.exe:15956): Spice-DEBUG: 17:17:06.227: ../src/channel-display-gst.c:792:gstvideo_has_codec: No video decoders from GStreamer for h265 were found
(remote-viewer.exe:15956): GSpice-DEBUG: 17:17:06.230: ../src/channel-display.c:894 GStreamer does not support the h265 codec
Any ideas how to fix this? Should I open a bug report >
<snipped>
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.
Found the reason: It's a regression in the windows version of remote-viewer. Was caused by libgstdirectsound.dll being replaced with libgstwasapi.dll and this changed the audio subsystem being used.
Details: https://gitlab.com/virt-viewer/virt-viewer/-/issues/2
Cheers,
Felix
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel