[Bug 731204] androidmedia: Implement zerocopy rendering

[GStreamer (GNOME Bugzilla)]

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

--- Comment #41 from Matthieu Bouron <matthieu.bouron at collabora.com> ---
(In reply to Sebastian Dröge (slomo) from comment #40)
> (In reply to Matthieu Bouron from comment #39)
> > (In reply to Sebastian Dröge (slomo) from comment #38)
> > > (In reply to Andoni Morales from comment #36)
> > > > We do already force applications to bundle some java code, the one used for
> > > > the initiallization. Couldn't we use this same piece to define the class
> > > > with the different listeners needed by our plugins? Or make ndk-build to
> > > > copy the Java files as proposed before, both would work and it requires no
> > > > interaction from the user. In case of the hardware decoders they can still
> > > > work without that, we can post a warning to inform the user if the listener
> > > > isn't found and error out for the camera plugin.
> > > 
> > > That was exactly what I proposed a few comments ago, yes ;)
> > 
> > As i've asked earlier, this solution requires that the activity or the
> > activity class loader to be known by the decoder in order to load the class.
> > 
> > The decoder would need to emit a message of type "android-app-activity", and
> > the application or GStreamer.java would need to handle it and provide the
> > object through a property or maybe using a context mechanism ?
> > 
> > I've started implementing this approach but i'd like to know if you think
> > this is acceptable before continuing because it requires a specific action
> > on the application level.
> > The first approach (bundling bytecode and which is currently implemented),
> > even with its downside seems less painful to deal with from the application
> > point of view.
> 
> Why do you need the application to do anything? If the class is included in
> the application, shouldn't it just require the JNI FindClass? We know the
> name of the class and also its package
> (org.freedesktop.gstreamer.androidmedia.MediaCodecWhateverThingy).

It looks like default FindClass is not able to find our class
(org.freedesktop.gstreamer.GstAMCOnFrameAvailableListener in this case) as the
default ClassLoader used by the jni env is the system ClassLoader which has no
visibily over the classes bundled with the application.

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