There are several parts of the spec which allow component to set the value of nOffset, there is also sample code which shows FBD can have nOffset set and pass it downstream (khronos tunnel conformance test resets nOffset to zero before calling OMX_FillThisBuffer)
Some are listed below - "A component uses the EmptyBufferDone callback to pass a buffer from an input port back to the IL client. A component sets the nOffset and nFilledLen values of the buffer header to reflect the portion of the buffer it consumed; for example, nFilledLen is set equal to 0x0 if completely consumed." With the help of nOffset, EmptyBufferDone provides a way to signal unconsumed data so that client can requeue unconsumed data at a later time. It is safe to let component choose nOffset value in case of OMX_AllocateBuffer() "A component uses the FillBufferDone callback to pass a buffer from an output port back to the IL client. A component sets the nOffset and nFilledLen of the buffer header to reflect the portion of the buffer it filled; for example, nFilledLen is equal to 0x0 if it contains no data)." "The OMX_UseBuffer implementation shall allocate the buffer header, populate it with the given input parameters, and pass it back via the ppBufferHdr output parameter " note that nOffset is not an input parameter Sample code from the spec with nOffset usage /* Traverse the list of extra data sections */ OMX_OTHER_EXTRADATATYPE *pExtra; OMX_U8 *pTmp = pBufferHdr->pBuffer + pBufferHdr->nOffset + pBufferHdr- >nFilledLen + 3; On Feb 25, 6:55 pm, v_dusan <[email protected]> wrote: > Depending on the use -case, the OMX component can implement a > workaround by > allocating its own buffers - apply the desired offset internally and > provide the pBuffer pointer > to the client with offset already applied. > > By doing this - the OMX component can implement the offset value > without involving the client. > > On Feb 25, 8:51 pm, v_dusan <[email protected]> wrote: > > > > > The OMX IL 1.1.2 spec does not specify explicitly who is responsible > > for setting the value of nOffset parameter in each buffer. (whether it > > is the OMX IL client or OMX component). > > Since there is no clear obligation on either client or component to > > set this value (and OMX components have been found that do not > > initialize this value) - to ensure the proper operation over a range > > of possible OMX components > > the OMX client sets the value of nOffset to 0. THis is not in > > collision with the omx spec in any way. > > The valid data in input the buffer starts where indicated. > > > Depending on your use-case - the component > > > On Feb 25, 8:43 pm, hdandroid <[email protected]> wrote: > > > > Looks like OpenCore does not understand the usage of nOffset field on > > > input port. There is no effect when component sets nOffset to a non- > > > zero value. OpenCore ignores nOffset and copies data into reserved > > > region (same behavior as when nOffset is set to Zero) > > > > >>>Sec 2.1.12 of OMX IL 1.1.2 > > > > The nOffset parameter indicates the number of bytes between the start > > > of the buffer and the start of valid data. The nFilledLen parameter > > > specifies the number of contiguous bytes of valid data in the buffer. > > > The valid data in the buffer is therefore located in the range pBuffer > > > + nOffset to pBuffer + nOffset + nFilledLen.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
