gst_element_set_state blocks when setting GST_STATE_NULL when using vaapisink and QWidget
viljar.hera at gmail.com
Sun Nov 14 10:23:54 UTC 2021
Thank you both for your suggestions.
I have now tried using glimagesink ("overlay" use case as before), however
but its seems to have the same problem as vaapisink. The same deadlock on
This happens on Intel hw as well when I tried the test code on a skylake
Am I missing something here....?
Kontakt Nicolas Dufresne (<nicolas at ndufresne.ca>) kirjutas kuupäeval K, 10.
november 2021 kell 17:43:
> Le mercredi 10 novembre 2021 à 19:55 +0530, Nirbheek Chauhan via
> a écrit :
> > On Wed, Nov 10, 2021 at 6:10 PM Viljar Hera <viljar.hera at gmail.com>
> > >
> > > Well because I need vaapi for hw acclerated decoding (vaapih264dec &
> > Vaapi can be transferred zerocopy to GL memory, so you do not need to
> > use a vaapi sink to do hw accelerated rendering of hw decoded buffers.
> Note that vaapisink is able to use an HW scaler not integrated in the GL
> We've had a use case for that in the past. While with GL integration, GPU
> scaling is going to be done. But to use vaapisink, you need an "overlay"
> case, which isn't very nice for modern qml gui. So I second your
> > > and the project does not use qml at all.
> > >
> > > Actually I have not tested qmlglsink before. My distro (arch linux)
> doesn't even provide the package. So I'm not sure how well it integrates
> with regular QWidgets.
> > >
> > You can always render to glimagesink and render to a GL surface with
> > Qt. There are examples for this:
> > Cheers,
> > Nirbheek
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel