Hey, One more issue I have with this series is that I reliably manage to get a hung spice-server with gstreamer:mjpeg and gstreamer:h264 I test it with you tube, and then hovering over the video seek bar so that lots of thumbnails are shown. I'm not sure whether it's an issue with these patches, a bug in my gstreamer installation or something else. If you have any hints at what I should look for to figure this out.. ;) Christophe On Tue, Mar 01, 2016 at 04:49:55PM +0100, Francois Gouget wrote: > > This patch series adds support for using GStreamer to encode and decode > the video streams, adding support for VP8 and h264 codecs. > > There have been quite a few changes since the last revision of this > patchset. > * The VP8 encoding performance has been improved. > * The zero-copy code for the input frame has been cleaned up. > * The Spice-Gtk architecture has been modified so the video decoder can > avoid dropping frames for inter-frame codecs (such as VP8 and h264) > as that causes artifacts. This should avoid the image quality issues > that sometimes happened while the bitrate was getting adjusted. > * The new Spice-gtk architecture also allows GStreamer to work on > more frames at once which could help with performance. > > > As before the patches can also be grabbed from the gst branch of the > repositories below: > > spice: https://github.com/fgouget/spice > spice-gtk: https://github.com/fgouget/spice-gtk > xf86-video-qxl: https://github.com/fgouget/xf86-video-qxl > spice-protocol: https://github.com/fgouget/spice-protocol > > See also gst-sync for the old spice-gtk code. (there's also 'extras' > branches with more experimental/future patches for the curious) > > > Changes from v9: > * Moved the codec parameters except the bitrate to the pipeline > 'gst-launch' string. That string is traced so this makes it easier to > see exactly how the codecs were configured. > * Updated how the video:codec preference string is handled to use a > GArray. > * Changed the VP8 encoder parameters to improve performance based on > the realtime profile. Furthermore it turns out that it is important to > get the number of physical cores right, and that's something the > encoder does not know how to do itself. > * Instead of waiting until the last millisecond to decode frames, > Spice-Gtk now lets the video decoders do the queuing. So in the > GStreamer case the GStreamer pipeline now does the queuing and > calls Spice-Gtk back when it's time to display the frame. > * That last point means mm-time adjustments don't apply to queued > frames. That does not really seem to be an issue but could be modified > if necessary. > > Changes from v8: > * Rebased on the current source. > * Adjusted the Spice protocol version requirement. > > Changes from v7: > * When the client has support for GStreamer video codecs it now > checks the presence of each supported codec before advertising support > for it. > > Changes from v6: > * configure.ac uses the new m4 macros to check for GStreamer support > and the presence of the needed plugins. > * It separates adding checks for the client codec support from > specifying which codec to use in the server and from adding VP8 > support. > > > -- > Francois Gouget <fgouget@xxxxxxxxxxxxxxx> > > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/spice-devel
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel