Il 21/05/2015 10:34, Fabio Fantoni ha scritto: > Il 13/05/2015 22:20, Francois Gouget ha scritto: >> This is a followup on Jeremy White's concept patch to use GStreamer: >> http://www.spinics.net/lists/spice-devel/msg10030.html >> >> 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, >> > 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. > > 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. Thanks for any reply.
Attachment:
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel