[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