[Spice-devel] [spice-gtk v1 3/4] channel-display-gst: improve check for decoder element

[Victor Toso]

Hi,

On Wed, Oct 19, 2016 at 04:43:12PM +0200, Francois Gouget wrote:
> On Wed, 19 Oct 2016, Victor Toso wrote:
> [...]
> > > In a different context I have found that I can fnid dfbvideosink and
> > > even instantiate it. But it will refuse to switch to the READY state and
> > > is thus unusable. That makes sense since I was not using it in a Direct
> > > FB context.
> > 
> > Interesting. Was it possible to set a dfb context later on? Otherwise it
> > could be a bug, no?
> 
> I don't think that's a bug. The GStreamer documentation says:
> 
> * GST_STATE_NULL: this is the default state. No resources are allocated 
>   in this state, so, transitioning to it will free all resources. 
>   [...]
> 
> * GST_STATE_READY: in the ready state, an element has allocated all of 
>   its global resources, that is, resources that can be kept within 
>   streams. You can think about opening devices, allocating buffers and 
>   so on. However, the stream is not opened in this state, so the stream 
>   positions is automatically zero. If a stream was previously opened, it 
>   should be closed in this state, and position, properties and such 
>   should be reset. 
> 
> When the dfbvideosink is instantiated is is in the NULL state and since 
> no resource is allocated in this state it does not matter whether the 
> device is available or not. It's only when transitioning to the READY 
> state that it would try to open the relevant device and so that's where 
> it returns an error.

Right, thanks for clarifying.

> > > I expect hardware decoders will be even worse. For instance vaapidecode
> > > is likely to be present but may not work if you don't have an Intel
> > > card. Even if you can instantiate it, it may cause a VP8 pipeline caps
> > > negotiation to fail if your graphics does not support VP8.
> >
> > Yes, that's why I think we need a different approach for hardware
> > decoders.
>
> We will need code that can try the hardware decoder first and fallback 
> to the software one if it's not usable.

If I understand correctly what ceyusa said [0], the fact that we can
only find the vaapi hardware decoder element if hw supports it.

[0] https://lists.freedesktop.org/archives/spice-devel/2016-October/032825.html

> 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.

Once again, I don't really mind to drop this patch, I just want to
understand why it is error prone / not reliable.

  toso
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20161019/9ced9df9/attachment.sig>