<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Il 25/05/2015 17:07, Fabio Fantoni ha
      scritto:<br>
    </div>
    <blockquote cite="mid:55633AC2.1070701@tiscali.it" type="cite">
      <pre wrap="">Il 21/05/2015 10:34, Fabio Fantoni ha scritto:
</pre>
      <blockquote type="cite">
        <pre wrap="">Il 13/05/2015 22:20, Francois Gouget ha scritto:
</pre>
        <blockquote type="cite">
          <pre wrap="">This is a followup on Jeremy White's concept patch to use GStreamer:
<a class="moz-txt-link-freetext" href="http://www.spinics.net/lists/spice-devel/msg10030.html">http://www.spinics.net/lists/spice-devel/msg10030.html</a>

There is still a lot of work ahead but this patches series has all the 
infrastructure so we're sending it out to verify that it looks ok.

First, with this patch series:
 1. You can use the SpiceVideoCodecs option in the xorg.conf file (or
    $XSPICE_VIDEO_CODECS) to set your video encoder and codec 
    preferences. The default is still the builtin MJPEG encoder.

 2. You can do the same from QEmu by setting the video-codecs option.

 3. Clients can expose new display capabilities to advertise that 
    they support either or both of the MJPEG and VP8 codecs. The new 
    server will automatically pick a codec they support based on the 
    above preference list. Older clients that don't advertise these new 
    capabilities will automatically get an MJPEG stream. So old and new 
    clients and servers should all be compatible.

 4. The GTK and and HTML5 clients have been updated to support both 
    MJPEG and VP8.

 5. Using GStreamer as the video encoder should work well for either 
    codecs as long as the stream does not hit your network connection's 
    bandwidth limit. Essentially this means it should be ok on LANs and 
    fast WiFi networks. This should even work with multiple clients.


There's one known issue in the framework: if the Spice server and 
clients have no codec in common, red_display_create_stream() will set 
video_encoder to NULL and that's not handled well. Currently this should 
really not happen as all clients support MJPEG and we have the builtin 
MJPEG encoder as a fallback. The root of the issue is that the 
red_display_create_stream() callers assume it will never fail. But I 
don't know how to change that yet.


The GStreamer backend still has a number of limitations:
 1. It's still based on GStreamer 0.10. I don't think moving to 1.0 
    will be a problem, if anything it should help (famous last words).
    For instance support for dynamically changing the bitrate appears to 
    be better in 1.0.

 2. It still does not have any rate control but should work fine as long 
    as the bandwidth is sufficient. The issue with rate control is that, 
    at least in 0.10, GStreamer encoders don't like bitrate changes, 
    need some time after each change to actually match the new bitrate, 
    still tend to exceed it from time to time, and sometimes just won't 
    get anywhere near it. Part of these issues are likely to be bugs in 
    the current implementation and it should be possible to work around 
    most others.


Feedback would be greatly appreciated.


Cheers,

</pre>
        </blockquote>
        <pre wrap="">Thanks for improving spice, I tried your patches, I applied the
spice-gtk, spice-protocol and I updated the git submodule to use right
spice-protocol but make of spice-common/common generate a new enum.h and
override the spice-protocol patch failing the spice-gtk build with vp8
codec undefined.
Seems that also a spice-common patch (at least in spice.proto) is needed
but missed in the patch serie posted.


</pre>
      </blockquote>
      <pre wrap="">
Some days ago I tested spice server and client updated and compatibility
with older of both seems ok.
Today I finally tested with video-codecs=gstreamer:vp8.
The video image often freezes for a moment (or probably until next imput
event or something).
qemu log have only some of this as particular:
Spice-Warning **: gstreamer_encoder.c:189:construct_pipeline: GStreamer
error: nessun elemento Â«appsrc»

You need full logs of spice server and/or spice with debug enabled?

If you need other informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.

</pre>
    </blockquote>
    <br>
    I solved the previous error installing gstreamer0.10-plugins-bad
    package, libav instead in debian is present only with gstreamer 1.0.<br>
    After din't show gstreamer warning anymore but still have image
    freeze and also spice-gtk crash after open video fullscreen, here
    the full gdb datas:<br>
    <a class="moz-txt-link-freetext" href="http://pastebin.com/idTkZLh0">http://pastebin.com/idTkZLh0</a><br>
    <br>
    <span>After I tried with gstreamer using ffmpeg, vp8 doesn't
      crashed, probably was problem of gstreamer0.10-plugins-<wbr>bad<wbr>
      but "image freeze" problem remain</span><br>
    <br>
    gstreamer:mjpeg seems similar to spice:mjpeg, both with some
    artifacts probably caused by mjpeg itself.<br>
    <br>
    <br>
    About vp8 image freeze <span>here some seconds of gst log debug on
      spice-gtk when problem happen:</span> <a class="moz-txt-link-freetext" href="http://pastebin.com/PP2R43Yf">http://pastebin.com/PP2R43Yf</a><br>
    Using spice:vp8 seems only have low performance.<br>
    <br>
    <br>
    <pre wrap="">If you need other informations/tests tell me and I'll post them.

Thanks for any reply and sorry for my bad english.</pre>
    <br>
  </body>
</html>