The spec notes that for video decoders, the size of the output buffers may need to change when they start decoding a stream. When this happens the component calls EventHandler with OMX_EventPortSettingsChanged. At this point, the decoder will not have generated any output data.
Since the component will have already taken the output buffer from the queue, should the component return the buffer to the client using a call to FillBufferDone but with nFilledLen set to zero? I imagine that the client just passes on the buffers as normal, so the consumer of the buffer will look at the length and do nothing with it (assuming flags, etc aren’t set). Is this the intention for hwo this works?
I guess this is implementation specific, but it probably applies to most implementations.
I would expect that the component should not return the buffers. The reason is that the client may detect that the buffers are empty and so return them to the component for filling. This would then lead to the buffer ping ponging between the component and client. In the general case this is more of a problem when the port is tunnelled with another component, but I’d do the same for both situations.
I think the correct behaviour is the port should keep hold of the buffers, and wait for the client to take action. After the port parameter changed notification the client should disable the port, which would result in the buffers being handed back to the client as part of the disable command - in this way, the component is sure that the client is expecting empty buffers. After getting the new parameters (and potentially changing the number of buffers, etc) the client would then enable the port again which would require new buffers to then be allocated.