[Spice-devel] [PATCH 0/11] Add GStreamer and VP8 support

[Francois Gouget]

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 at codeweavers.com>