On Wed, 19 Oct 2016, Victor Toso wrote: [...] > > But I don't think this necessarily impacts gstvideo_has_codec() if > > implemented using create_gstreamer_decoder() whereas with your code it > > will necessarily be impacted. > > Well, my point is simply why create the whole pipeline if we only need > to check if element is present. As I said above, it might even be enough > to check if we have hw decoding by adding vaapijpegdec, vaapih264dec, > and so on. So gstvideo_has_codec() will have to know about vaapijpegdec, vaapih264dec, and so on. And create_gstreamer_decoder() will need to know about them too. Whereas with the current code only create_gstreamer_decoder() has to know about them. > Once again, I don't really mind to drop this patch, I just want to > understand why it is error prone / not reliable. It relies on GStreamer elements being 'visible' only if their resources are available which is not how GStreamer worked up to August 2016 (1.8.3). That it works this way in 1.9 for the vaapi set of decoders is nice, but will it be true of other hardware decoders too? Also are we sure we will not want to support hardware decoding with GStreamer 1.8? 1.8.3 is only a few months old. But really I don't see any tangible benefit to this change so I'm in favor of keeping the code simple. -- Francois Gouget <fgouget@xxxxxxxxxxxxxxx> _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel