Results 1 to 2 of 2


  1. #1
    Junior Member
    Join Date
    Mar 2012



    I tried to implement a openmax il image decoder.
    In the longrun it should be integrated into Qt, for now it just need to be a PoC-application.

    Here is the code:

    My code runs on a Broadcom Rasperry PI.
    The setup is that I've a decoder ("OMX.broadcom.image_decode") and a renderer("OMX.broadcom.egl_render").
    The output of the decoder and the input of the renderer are tunneled.

    After a while struggling with openmax il, I finally got to a state where nearly everything seams to work. So far this seams to work:
    - initial setup
    - tunneling
    - buffer allocation
    (OMX_AllocateBuffer for decoder-input-port and OMX_UseEGLImage for renderer-output-port)
    - both go into OMX_StateIdle
    - both go into OMX_StateExecuting
    - OMX_EmptyThisBuffer on decoder-input-port seems to work
    (although one thing: is it normal that you don't get a callback on that if the output port is tunneled?)

    ... but I got problems with OMX_FillThisBuffer

    First of all: It's only returning after a fresh reboot, if I start the application a second time OMX_FillThisBuffer will not return anymore.

    But I guess (/hope) that's another problem, if OMX_FillThisBuffer "succeeds", I will not(!) get a fillBufferDone-callback until(!) I disable the renderer-output-port ... is that normal?

    ... and if I do I think I get a error within the callback:
    pBufferHeader->nFlags == 221

    which means the OMX_BUFFERFLAG_DATACORRUPT is set .. right?
    Therefor I tried other image files ... jpg and png, non is working.

    The problem in the end is, that the texture, on which the used EGLImage is bound isn't changing at all.

    Anyone and idea?


  2. #2
    Junior Member
    Join Date
    Mar 2012


    I got the tip to wrap my omx-includes with #pragma pack(4), like this:

    #pragma pack(4)
    #include "IL/OMX_Core.h"
    #include "IL/OMX_Image.h"
    #include "IL/OMX_Component.h"
    #pragma pack()

    This changed the nFlags value I get in the fillBufferDone-callback
    from: pBufferHeader->nFlags == 221
    to: pBufferHeader->nFlags == 0

    which I guess is the correct value now ... maybe ... any opinion?

    ... anyway: besides the changed value... it's still all the same. The texture doesn't change.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Proudly hosted by Digital Ocean