[Spice-devel] [PATCH spice-gtk] gst: Fix detection of h264 stream decoder

[Pavel Grunt]

On Wed, 2017-07-19 at 18:00 +0200, Christophe Fergeau wrote:
> On Wed, Jul 19, 2017 at 05:46:51PM +0200, Victor Toso wrote:
> > What I'm trying to stress is that we are trying to not check *specific*
> > plugins related to decode/parse a stream. We don't know what our users
> > will be using and we should not enforce them to use avdec_h264 for
> > instance. You are doing this in this patch and that's why I'm against
> > it.
> 

Hi Christophe,

this patch is really not enforcing usage of any plugin. It's just making work
what used to work before c9209aef946b3ad517e7794d2e5648caf5ee2bf9. It does not
switch from GstCaps to checking by names. The checking by names is just an extra
addition to make sure that we don't forget about elements that could be filter
out due to *our* usage of GstCaps & gst_element_factory_list_filter()

> Yes, actually, on fedora you won't get avdec_h264 unless you enable RPM
> Fusion, and you might prefer to go the Cisco openh264 road instead
> ( https://ausil.us/wordpress/?p=126 - assuming this is still the
> recommended way to go with Workstation these days).

openh264 can be used only for WebRTC (at least for now). In general you need to
enable the 3rd party repo to get h246 - even for Cisco's openh264

https://fedoraproject.org/wiki/OpenH264

> So yeah my feeling
> would be to avoid hardcoding plugin names, assuming we can fallback
> properly if the decoding fails. 

we got this streaming features thanks to contribution from community, I don't
see a reason for breaking it and doing a release. Let's break (= improve) it
after that (removing configure checks for plugins, Victor's FIXME and my TODO).

> We could also try to make use of the
> 'missing-codec' GStreamer infrastructure if we want to get fancy.
> 
Yeah, that would be a nice RFE for a newcomer to learn about SPICE protocol.
Whether it is useful or annoying, it's a different question :)

Thanks,
Pavel

P.S.: In fact for gstreamer < 1.9 we should check for the plugin only by their
names (or by launching the pipeline). Because with the current approach it can
happen that an element for hw decoding is present (and the capability is
reported to the server) however a different (possibly missing sw decoding)
element is used in the gstreamer's decoding pipeline.