|
Il 25/05/2015 17:07, Fabio Fantoni ha
scritto:
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. I solved the previous error installing gstreamer0.10-plugins-bad package, libav instead in debian is present only with gstreamer 1.0. 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: http://pastebin.com/idTkZLh0 After I tried with gstreamer using ffmpeg, vp8 doesn't crashed, probably was problem of gstreamer0.10-plugins- gstreamer:mjpeg seems similar to spice:mjpeg, both with some artifacts probably caused by mjpeg itself. About vp8 image freeze here some seconds of gst log debug on spice-gtk when problem happen: http://pastebin.com/PP2R43Yf Using spice:vp8 seems only have low performance. If you need other informations/tests tell me and I'll post them. Thanks for any reply and sorry for my bad english. |
Attachment:
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel