Results 1 to 2 of 2

Thread: OMX IL Clarification for usage of EOS Flag

Hybrid View

  1. #1
    Junior Member
    Join Date
    Feb 2013
    Posts
    2

    OMX IL Clarification for usage of EOS Flag

    (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.
    (C) 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.

    1) 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?
    2) Can IL Clients not use an input buffer with nFilledLen = 0 and EOS to propagate metadata information independent of payload?
    3) 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.

  2. #2
    Junior Member
    Join Date
    Feb 2013
    Posts
    2
    >>1) 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?

    OMX Spec 1.2 says following wrt nFlags
    "nFlags field contains buffer specific flags, such as the EOS flag. A component should propagate this field from an input buffer to its associated output buffer."

    >>2) Can IL Clients not use an input buffer with nFilledLen = 0 and EOS to propagate metadata information independent of payload?
    This is case C in above examples. I would interpret that this case is OK as mentioned. Khronos OMX CTS has similar test. Although i do not think that it does single buffer EoS test.

    >>3) Can a component copy metadata information in two separate input buffers onto a single output buffer including EOS?
    I am not entirely clear about the query here. My interpretation is that Spec do not restrict to club nFlags of two differnet input buffers to a single output buffer, provided it is the "associated output buffer". That is, for ex, case A may also be valid.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •