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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel