On Tue, Feb 16, 2016 at 10:41 AM, wm4 <nfx...@googlemail.com> wrote: > On Mon, 15 Feb 2016 18:52:25 +0100 > Matthieu Bouron <matthieu.bou...@gmail.com> wrote: > > > Hello, > > > > The following patchset adds basic MediaCodec support to libavcodec, ie: > only > > h264 is supported and the HWAccel part (Surface output) is missing. > > > > JNI comes as a dependency. The JNI support is based on the same patchset > I've > > sent some time ago with some improvements. > > > > I originally developed the patch against the Ndk API (Android >= 5.0) > but then > > changed my mind and go with the JNI version for two main reasons: > > > > * there are still too many android 4 devices > > * there is still needs for some jni bits as the MediaCodec Ndk API > > does not provide a way to known the codec name which is mandatory > > to workaround or blacklist some implementations (ie: do not use known > > software decoders, workaround OMX.SEC.avc.dec as it returns invalid > > stride and slice-height values, ...) > > > > I guess there's no way around it. > > > I decided to mimic the Ndk API minus a few differences (see > > mediacodec_wrapper.h) so it can be ported more easily to the C API in the > > future. The other reason being it is to totally hide the JNI code. > > > > The HWAccel part is on my todo list but I wanted a real use case to > develop the > > API against. > > > > The development branch can be found here: > > https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support > > > > --enable-jni and --enable-mediacodec is required to build the > h264_mediacodec > > decoder. > > > > av_jni_register_java_vm(vm) must called before lavc is used. > > Wasn't there some sort of trick that could avoid this? >
The workaround for this is to call a *private* C++ API, and in particular checking that the variable jni_invocation_ is initialized and call the GetCreatedJavaVMS function from: https://android.googlesource.com/platform/libnativehelper/+/master/JniInvocation.cpp > > The patchset also includes supports for Android content uris which is not > > mandatory for the mediacodec supports but helps dealing with them more > > seamlessly. > > I'm still not convinced that this is necessary (custom I/O allows any > application to provide its own I/O callbacks). This would also avoid > the need for avpriv JNI API, since it'd be confined to libavcodec. > Content uris are the proper way to deal with medias on Android since version 5.0. Having it in lavf as a protocol would prevent anyone who wants to support it in its application to re-do a custom io wrapper around it. IMHO, it's like the other protocols we already support (samba, ssh, gopher, icecast, ...) and the code that adds its support is not intrusive (it just returns a fd that is then used by the file protocol functions). The issue here is its jni dependency right ? > > > In order to use this support, av_jni_register_application_context(env, > context) > > must be called before lavf/lavu is used. > > For "content URIs"? > Yes for content uris usage. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
