OMX_BUFFERFLAG_DATACORRUPT

Hi,

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: https://gitorious.org/openmax-il-qt-image-decoder-poc

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?

Greets
Thomas

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 :wink: … any opinion?

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

Greets
Thomas