[vlc-devel] [RFC PATCH 00/11] OMX: enable android hardware buffers (zero copy)
Thomas Guillem
guillem at archos.com
Tue Jun 24 16:15:02 CEST 2014
Hello guys,
This set of patches is my first attempt to backport android hardware buffers in
OMX from the Archos Video Player application that I'm working on.
These patches can be useful for android versions older than JellyBean, since
MediaCodec is not working well on all hardware before JellyBean MR2.
In order to have android hardware buffers working on OMX, I had to:
- add iomx_hwbuffer.c: a wrapper to native_window API that can be found in
aosp system/window.h. It's not the same API than the one we can find in
android-ndk even if it share the same object. This private API allows to
queue/dequeue HW buffers allocated with a specified hal_format and hw_usage.
I'm not sure of the name of the file here, maybe it should be called
private_native_window, system_native_window or maybe we should merge it with
existing native_window code. I put the iomx_ prefix since that code is build
in libiomx-*.so against the different android headers.
- patch iomx.cpp: implement OMX_UseBuffer, OMXAndroid_EnableGraphicBuffers,
OMXAndroid_GetGraphicBufferUsage. Once you call
OMXAndroid_EnableGraphicBuffers(), OMX will give you a eColorFormat that is
in fact the hardware dependent hal_format that is needed to allocate the HW
buffer via iomx_hwbuffer.
- patch omxil.cpp: If we are in direct mode, I Allocate HW buffers, and run a
thread that will dequeue all buffers and send them to a new fifo. In
DecodeVideo, I recover all available HW buffers from the new fifo and send
them to OMX (non waitings calls). If the buffer is a HW buffer, I setup the
pf_display_callback to a function that will queue the buffer (and display
it). I'm glad that the "video_output/android/opaque.c" that was developed
for MediaCodec is also working great for my case.
Theses patches don't break anything on OMX, if the extra android symbols needed
to use HW buffers are not found, it falls back to non direct buffer mode.
I did the development on a Nexus 10 with last android 4.4.3, and I have a
performance issue using HW buffers. I need to investigate more since I know
that I don't have any performances issue with my other player. I also tested it
on a RK30 and a QCOM device.
By the way, I don't know if you want the patches to enable libiomx build on jb
and kitkat (mostly android headers patch).
Any comments are welcome.
Best regards,
Thomas Guillem.
Thomas Guillem (11):
Ignore android build dirs
iomx: simplify param/config size getter.
Android vout: check chroma before lib init
iomx: implement OMX_UseBuffer
iomx: add iomx_hwbuffer
iomx: add android GraphicBuffers functions.
omxil: factorize FreeBuffers and AllocateBuffers
omxil: more error check
omxil: fix warnings
omxil: factorize OMX_FIFO init/destroy
omxil: add android hw buffers support (zero copy)
.gitignore | 2 +-
contrib/.gitignore | 1 +
modules/codec/omxil/iomx.cpp | 131 +++--
modules/codec/omxil/iomx_hwbuffer.c | 199 +++++++
modules/codec/omxil/omxil.c | 892 ++++++++++++++++++++++++--------
modules/codec/omxil/omxil.h | 55 +-
modules/codec/omxil/omxil_core.c | 21 +
modules/codec/omxil/omxil_core.h | 14 +
modules/codec/omxil/omxil_utils.h | 10 +
modules/video_output/android/surface.c | 9 +-
10 files changed, 1042 insertions(+), 292 deletions(-)
create mode 100644 modules/codec/omxil/iomx_hwbuffer.c
--
1.7.10.4
--
This email and any files transmitted with it are confidential and are
intended solely for the use of the individual or entity to which they are
addressed. Access to this e-mail by anyone else is unauthorised. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited.
E-mail messages are not necessarily secure. Archos does not accept
responsibility for any changes made to this message after it was sent.
More information about the vlc-devel
mailing list