[Bug 731204] androidmedia: Implement zerocopy rendering

[GStreamer (GNOME Bugzilla)]

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

--- Comment #47 from Matthieu Bouron <matthieu.bouron at collabora.com> ---
(In reply to Sebastian Dröge (slomo) from comment #46)
> (In reply to Edward Hervey from comment #44)
> > The part about non-Java apps leaves me a bit ... dubious. How can you have
> > non-java apps on Android *unless* you are doing "system" applications ? Any
> > app *will* need a java loader (albeit as small as possible).
> 
> Xamarin and Qt are hiding all that from the application.
> 
> (In reply to Matthieu Bouron from comment #45)
> > (In reply to Edward Hervey from comment #44)
> > > The part about non-Java apps leaves me a bit ... dubious. How can you have
> > > non-java apps on Android *unless* you are doing "system" applications ? Any
> > > app *will* need a java loader (albeit as small as possible).
> > > 
> > > As for storing/using the activity in GStreamer.init() it makes sense imho.
> > 
> > I'm not sure passing the activity to Gstreamer.init and stores it as a
> > static variable will really help unless some kind of C api is provided by
> > gstreamer-android to retreive the activity from there and also because the
> > application (activity) is currently stored in CustomData.app (it is already
> > done for all android tutorials, the code is not shared though).
> > Maybe i'm missing something here.
> 
> Why can't we get org.freedesktop.gstreamer.GStreamer via JNI's FindClass()
> and then directly use the field from there? It's clearly loaded at this
> point as the application called it :)

It is not a matter of the class being loaded or not. It just depends on the
class loader that is going to be used. The class loader used by default by the
JNI env is the system class loader and it has no visibility over the classes
bundled by the application. The class loader provided by the
application/activity must be used instead if we want to load our classes.

So I think we need to add some kind of API at the gstreamer level on which the
decoder could depend, and use to retreive the activity or activity class
loader.

The application would be in charge of providing it through this API.
The application will also have to take care of providing a new object reference
each time the JNI thread has changed as the old object reference in the C world
won't be valid anymore.

What do you think ?
Which solution should we focus on ?

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