[Bug 756082] qmlglsink: add a QML extension plugin

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(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.

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.

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

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

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

> 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? Dynamic or statically linked
plugins? I'd say we should try (if possible) to do whatever developers on those
platforms are used to.
Otherwise for a static plugin, we could probably initialize that during
plugin_init() too for Qt?

> Still my above problem needs to be solved: how to inject the Qt-dependcies
> in a cerbero-build. Unless you plan to build Qt *inside* the cerbero env --
> would you!?? -- the pkg-config deps would need to be injected from outside
> the build-env. How do you plan to handle this?

See above :) Building Qt is also an option, but it's absolutely non-trivial on
non-Linux platforms... or at least was 3 years ago. I'd just create a recipe
with their binaries.

Qt should not be enabled by default though, it should be an variant.

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