[Spice-devel] [PATCH 0/11] Add GStreamer and VP8 support
Francois Gouget
fgouget at codeweavers.com
Tue Jun 9 01:48:44 PDT 2015
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>
More information about the Spice-devel
mailing list