[Bug 789475] omx: wait for flush complete and buffers being released when flushing

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=789475

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #12 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
Unfortunately, this was wrong. gst_omx_port_set_flushing() now waits for all
the buffers in the pipeline to come back, while it was suppose to wait for the
flush command to complete. How it works:

 - We send the OMX_CommandFlush
 - Then our handles will receive it and serialize into our message queue
 - We call gst_omx_component_handle_messages()
 - And then check for port->flushed or wait for the message to arrive

All this is protected with the comp->lock. About the && check, it was an
optimization, because it's pointless to wait for the message if all buffers are
pending. The component is still being flushed, but we can avoid the waiting
(OMX stack can be slow).

I'm not too sure why we unblock anything waiting for message, it's seems
pointless but harmless. I might be missing something.

To come back to why it's wrong, the code has been changed so now it wait for
all buffers from the entire pipeline to come back. This just impossible,
buffers stuck in display sink (last-sample or scannout if kmssink) will only be
returned if a new buffers replace them or an allocation/drain query is
received. As a side effect, we now always reach the timeout.

Though, we should check the the OMX stack have behaved properly and returned
the buffers that was in the OMX stack. Currently, we don't track this, we have
no idea which outstanding buffers are in the OMX stack and which one are
downstream the pipeline.

In my opinion though, if you received OMX_CommandFlush and the buffers were not
returned yet, this is an error. What you seems to have fixed here is a bug in
the Zynq OMX stack.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.