On Thu, 4 Jun 2015, Fabio Fantoni wrote: [...] > No bandwidth limit, on client I saw use between 1 and 3 mb, both server > and client have 1 gbps cabled network (lan). > Server used for testing is a dell PE T310 with cpu xeon X3450 is asus > K53S with core i5-2430M. > Server cpu usage of qemu process is over 300% on streming video. > spice streaming video setting is 'all' and codec 'gstreamer:vp8', no > error/warning in qemu logs. > I used github.com/fgouget/spice-gtk/commits/gst including "avoid > gstreamer deadlock" and github.com/fgouget/spice/commits/gst in latest test. > Client cpu and network usage seems low but streaming video is bad (with > vp8), here a small video example done with smartphone: > http://fantu.it/vari/spice-gtk-vp8.mp4 The video looks like there are two issues: * The video corruption. It looks like an I frame was lost and the following P frames were thus decoded incorrectly. This is a bit strange because in my experience VP8 throws the P frames in such a case (so they are not displayed, unlike in h264's case). * The short pause every few seconds. This may be related to the previous issue: I frames are bigger than P frames. Maybe they take too long coming across, thus forcing the client to pause waiting for them, and maybe that's also why they sometimes get lost. But given your network specifications that should not be the case. I have done tests with StreamingVideo=all here but it worked as well as when set to filter so that's probably not the source of the difference. Overall I suspect more a problem on the server-side. Here's what you can do: * First on the server check for messages that indicate some frames were dropped like the ones below (SPICE_DEBUG_LEVEL=9): (../xf86-video-qxl/scripts/Xspice:31980): SpiceWorker-Debug **: red_worker.c:3378:pre_stream_item_swap: ignoring drop, same pcg as previous frame 296 (../xf86-video-qxl/scripts/Xspice:31980): SpiceWorker-Debug **: red_worker.c:10643:display_channel_release_item: not pushed (101) As far as I understand it's the second message that indicates a frame has been dropped, but it systematically follows the first one so they are related. These happen even when there's no bandwidth issue and only happen in the GStreamer 1.0 case. And I have no idea what's causing this so far :-( * You can also look for 'server frame drop' in the server log. Unlike the messages above, those would indicate a network problem. * In gstreamer_encoder.c you may try adding a line like the following near the start of adjust_bit_rate() to see if constraining the bandwidth helps: encoder->bit_rate = 1024 * 1024 * 3; In the server log you can also look for 'base-bit-rate' and 'setting the bit rate' to see what Spice and gstreamer_encoder think of the bitrate respectively. * Do you have the same issue if you use gstreamer:mjpeg on the server? If gstreamer:mjpeg works fine then we'll know it's not a general GStreamer issue but more a codec-specific one. * The next thing to try would be gstreamer:h264. h264 is quite similar to vp8 in caracteristics: it has I and P frames too and also uses quite a bit of CPU, though it seems to handle threading a bit better. * Then if you can try running the server with GStreamer 0.10 this would let us determine if it's a GStreamer version problem. * The CPU usage on the server, 300%, does seem a bit high though for a 4C/8T CPU it should be manageable. Unfortunately gstreamer_encoder already tunes vp8enc for speed. Maybe setting threads=4 or 5, or cpu-used=16 can speed it up some more. For network usage maybe max-intra-bitrate can help. -- Francois Gouget <fgouget@xxxxxxxxxxxxxxx> _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel