One of the ports of component is base profiled. This port is supplier; hence IL client requests this port to allocate buffers using OMX_AllocateBuffer when transitioning the component from Loaded to Idle state. And later, the client transitions the component to executing for data flow. Then, unwinds the graph by transitioning component to idle and then loaded state.
When the Component is transitioned from executing to idle, Section 126.96.36.199.3.1 of the specification says that "If the IL client requests a state transition from OMX_StateExecuting to OMX_StateIdle, the component shall return all buffers to their respective suppliers and receive all buffers belonging to its supplier ports before completing the transition. Any port communicating with the IL client shall return any buffers it is holding via EmptyBufferDone and FillBufferDone callbacks, which are used by input and output ports, respectively.[…]" This is also shown in sequence diagram in section 188.8.131.52 Non-tunneled De-initialization (to be more specific, see step 1.1 "The component shall flush all of the buffers currently being processed by the calling relevant callback FillBufferDone or EmptyBufferDone")
The Issue is in the behaviour expected when the component is transitioned from executing to idle which seems ambiguous or open to interpretation for the described use case. The following two interpretations seem to be possible:
- One interpretation (which I favour) is as follows: the non-supplier port must return buffers to IL Client via EmptyBufferDone and FillBufferDone callbacks and the supplier port must receive buffers from the IL Client (i.e. with FillThisBuffer/EmptyThisBuffer calls)
- The alternative interpretation could be that the client does not have an obligation to return the buffers to the supplier port and that the component should not wait for the supplier port to receive any pending buffer when requested to transition from Executing to Idle.
Please find attached PDF file which has two sequence diagrams: “1.Actual_behaviour_in_Spec_Of_Non-tunneled_de-initialization” and “2.Explicit_Clarification_Of_Non-tunneled_de-initialization”.
The 2nd figure represents the first interpretation explicitly mentioning the expected behaviour on both the client and the component sides.
Created attachment 82 [details]
Ambiguous specification "Non-Tunnelled De-initialization"