(A) The IL Client submits an I-Frame to the OMX Component (decoder) in a first input buffer marked with EOF flag. It then submits a second input buffer with nFilledLen = 0 and EOS flag set.
The OMX Component generates a “single” output buffer with both EOF and EOS flag set.
(B) In another instance of same use case, if the second buffer was submit with nFilledlen = 1 and EOS flag set, the component generates “two” buffers on output. First with EOF flag set and second with EOS flag set and nFilledLen = 0.
© In yet another instance of component, if IL Client submits a single input buffer with EOS flag and nFilledLen = 0, it generates a “single” output buffer with EOS flag and nFilledLen = 0.
We integrate OMX components from various vendors into MMF and the belief is that all OMX components would propagate flags consistently in this case and thought the IL client is portable. But it appears, vendor implementations are not consistent in the manner flags are propagated to IL Client for this use case.
- Does the IL specification (1.1.2) define rules on how EOS should be propagated consistently or it is up to components to propagate the EOS flag as they like based on use case?
- Can IL Clients not use an input buffer with nFilledLen = 0 and EOS to propagate metadata information independent of payload?
- Can a component copy metadata information in two separate input buffers onto a single output buffer including EOS?
Our vendor recommends the above behavior is as per OpenMAX spec but there is not much clarity on this in the spec.
May I request the Working Group to provide clarity on such use cases and preferably mention exceptions in next version if any for benefit of implementations.