FILL BUFFER DONE & OUTPUT BUFFERS As for FillBufferDone - the OpenCore IS taking into account the "nOffset" set by the component for OUTPUT buffers. When the OMX component fills the data in the output buffer, it informs OMX client where the valid data begins. So, the OpenCore OMX client is taking the nOffset value into account. Please refer to .../nodes/pvomxbasedecnode/src/pvmf_omx_basedec_node.cpp @ FillBufferDoneProcessing method
EMPTY THIS BUFFER & INPUT BUFFERS 1) When the OpenCore OMX Client is passing input data to the OMX component - it also fills the input data into the buffer and sets the "nOffset" value to indicate to the OMX component where the valid data begins(before making the EmptyThisBuffer call). There is nothing in the OMX spec that prevents the OMX client to also set the value of nOffset in the input buffers. The OMX component needs to be able to handle this. 2) If the OMX component might try to apply some constant nOffset value for each buffer at initialization/buffer allocation - observe that this is problematic due to issue described in 1) 3) If the OMX component returns a partially consumed input buffer (say, buffer N) - consider the following scenario: - OMX client sends input buffers N, N+1, N+2, N+3, N+4 to the OMX component using EmptyThisBuffer calls - OMX component queues input buffers N,N+1,N+2,N+3,N+4 - OMX component partially consumes buffer N and returns it to the OMX client - Theoretically - Opencore OMX client could return this buffer N to the OMX component right away (applying EmptyThisBuffer call on it and taking into consideration the nOffset value). In such a scenario - there are multiple serious issues with the design of the OMX component: a) the client would be re-sending buffer N to the OMX component - and this data would now be out - of -order (with the buffers N+1, N+2, N+3 and N+4 already queued). The OMX component would then have to apply additional logic to properly place the input buffers in their correct order b) is buffer re-ordering in this case always possible is another question c) to avoid the problem of buffer re-ordering to place data in correct order - the OMX client would have to send input buffers one - by -one and wait until each input buffer is processed in its entirety by omx component (with possibly OMX Client resending the same input buffer multiple times to the OMX component until it is consumed) - which is not a reasonable request. In face of these issues - re-sending the partially consumed buffer to the OMX component looks very problematic. Does it even make sense? Why would the OMX component return a partially consumed input buffer only to get it back immediately and have to deal with buffer re- ordering? Why doesn't the OMX component hold the input buffer until it consumes it completely - and then return it back to the client? With all this in mind - the OpenCore discards partially consumed input buffers returned by the OMX component. I hope this helps, Dusan > 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 -~----------~----~----~----~------~----~------~--~---
