[Bug 756082] qmlglsink: add a QML extension plugin

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=756082

--- Comment #13 from Holger Kaelberer <hk at getslash.de> ---
(In reply to Sebastian Dröge (slomo) from comment #12)
> (In reply to Holger Kaelberer from comment #11)
> > - Cerbero: Did not find a way to inject 'foreign' PKG_CONFIG_PATH into the
> > cerbero build-env when linking against installed Qt-for-android. Hacked it
> > into the cerbero-code. Is there a way?
> 
> I guess the best here would be to have a Qt recipe that downloads the
> binaries from their website and then places them somewhere in the cerbero
> dist directory. Then pkg-config would directly find it.

>From a GStreamer PoV probably the cleanest solution. Then the Qt developer
needs to assure to use a Qt SDK that is compatible with the one used to build
GStreamers qml plugin.

> 
> Alternatively you could adjust the PKG_CONFIG_PATH from the gst-plugins-bad
> recipe, however that would require knowing somehow where Qt was placed
> manually before.

Thanks, works now ;-)

> 
> > - autotools: I did not find a way to build both static *and* shared libs
> > (for the qml-module) in one go during cross-building a gst-stack for android
> > with cerbero. This might be due to my poor knowledge of autotools, though.
> > This for now would be a showstopper for me building a shared qml plugin for
> > android.
> 
> That's why there is a gst-plugins-bad-1.0.recipe and
> gst-plugins-bad-1.0-static.recipe :) Building both at once is not trivial
> with autotools unfortunately.

So you mean first cross build gst-plugins-bad-1.0-static.recipe and then into
the same dist gst-plugins-bad-1.0.recipe?

> 
> > - cerbero: When manually resolving the dependencies for the qt-module from
> > the .la file the tools.mk from cerbero produced a syntactically wrong
> > linking command. Hacked around this in tools.mk. Once we agreed upon how to
> > build the qml module and this is still an issue, I'd come up with a patch
> > for that.
> 
> How was it syntactically wrong?

It appended something like "Qt5Gui Qt5Core ... " instead of "-lQt5Gui -lQt5Core
... "

> 
> > - gst-plugins-bad: iiuc the qtsink plugin is badly named atm. The .so file
> > should probably be named as the plugin ("libgstqt.so" instead of
> > "libgstqtsink.so") otherwise the ndk-build generates wrong code with the
> > GST_PLUGIN_STATIC_DECLARE macros. Right?
> 
> Yes
> 
> > - Having modfied the tests/examples/qt/qml/ to build for android, bundling
> > in a gstreamer_android.so I finally ran into an Android error:
> > 
> > E/BufferQueue( 1855):
> > [org.freedesktop.gstreamer.play/org.qtproject.qt5.android.bindings.
> > QtActivity] dequeueBuffer: SurfaceTexture has been abandoned!
> > E/[EGL-ERROR]( 2729): void __egl_platform_dequeue_buffer(egl_surface*):1271:
> > failed to dequeue buffer from native window (0x535dc6e8); err = -19, buf =
> > 0x52262974
> > E/BufferQueue( 1855):
> > [org.freedesktop.gstreamer.play/org.qtproject.qt5.android.bindings.
> > QtActivity] setBufferCount: SurfaceTexture has been abandoned!
> > E/SurfaceTextureClient( 2729): ISurfaceTexture::setBufferCount(0) returned
> > No such device
> > 
> > Not sure if this is a gst- or a qt/qml-problem. Have not yet been digging
> > deeper ...
> 
> I'd say that's a problem in our plugin. Can you create another bug for that?

Will do once there is a clean way to reproduce it.

>  
> > To sum up: Building the qml-module as a shared one for android seems to be
> > hard work if possible at all. Then, on iOS from what I googled about it
> > static linking is mandatory. Given that, I tend to agree with you that on
> > (these) mobile platforms linking everything statically might be the best way
> > to go. Ok?
> 
> What are Qt developers doing on Android usually?

The QML plugins shipped with Qt are bundled as shared libs.

> Dynamic or statically
> linked plugins? I'd say we should try (if possible) to do whatever
> developers on those platforms are used to.

I don't know how to link that using cerbero: Manually I linked all gstreamer
dependcies statically and only the Qt ones dynamically, which is probably the
best option. Otherwise, if you link everything dynamically you'd need to bundle
all shared dependencies in your apk!

How would the first option be done in a cerbero build? The static libs would
need to be available in the shared build. Would you first build a complete
xxx-static dist, then, on top, a shared stack?

> Otherwise for a static plugin, we could probably initialize that during
> plugin_init() too for Qt?

That is how it was done so far.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.