Hi, On Wed, Oct 19, 2016 at 06:26:18PM +0200, Francois Gouget wrote: > 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? That's a good question. So, the current code makes it possible to detect hw decoding for more versions of gstreamer... sounds good reason to me. > > 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. I do. For me it seems simpler checking if an element exist instead of creating the whole pipeline and then dropping it. I'll remove this change for now and send a v2 with the other requested changes. Many thanks for the review and discussion, toso
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel