[Bug 756082] qmlglsink: add a QML extension plugin

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Mon Dec 14 12:39:25 PST 2015


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

--- Comment #8 from Holger Kaelberer <hk at getslash.de> ---
I had a first look at how the android build-env for gstreamer works and
understand your concerns better -- not having found a single dir containing .so
files :-)

If you want to keep that direction I'd try to add a way to build and initialize
the qml-plugin statically, which corresponds to your 2nd alternative, slomo. We
wouldn't have won much then compared to the status quo.

Again from the Qt perspective I'd keep the split between 

1. a statically linked libgstqtsink.a supposed to be linked like the rest of
the gstreamer-on-android world
2. a dynamically linked qml plugin/glvideoitemplugin.so that could be used by a
Qt application in the Qt way

What would be the use-case for GstGLVideoSink on android? The user wants to
render a decoded video directly into this Qt-Item, i.e. integrate
GStreamer-based decoding in a QML scene. Then he would probably build a Qt/QML
application in the first place (using GStreamer under the hood) and use the Qt
tools (qmake/cmake) to create an apk-bundle. In most of the cases (unless tools
like ministro are used) the apk would be a standalone app. Then the
glvideoitemplugin.so would perfectly well integrate into the Qt build-process
and being packaged as the other qml plugins are. Also the gstreamer_android.so
would need to be bundled into the Qt-app.

Don't understand enough about the internals of gstreamer apps on android to see
how this would look like in detail.

Would be nice to have a testbed for that. Will have a look at how cerbero works
...

There not yet anything from -bad/ext/qt/ in the latest android tarballs, is it?

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


More information about the gstreamer-bugs mailing list