[Bug 759043] New: gst-omx: Timeout waiting for egl_render port 221 buffer release triggers subsequent "Insufficient resources" errors

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 759043
           Summary: gst-omx: Timeout waiting for egl_render port 221
                    buffer release triggers subsequent "Insufficient
                    resources" errors
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-omx
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: eocanha at igalia.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 316786
  --> https://bugzilla.gnome.org/attachment.cgi?id=316786&action=edit
Our pipeline

We're working on a Raspberry Pi 2. We have an OMXH264Dec element configured to
output EGL buffers (see attached pipeline), which means that internally there
are two OpenMAX components playing together, video_decode and egl_render[1].
They're not tunneled, according to the values shown by gdb.

During the execution of one of our tests (VideoChangeRate from YouTube 2015, on
WebKitForWayland), a call to gst_omx_video_dec_set_format()[2] is performed.
That call performs several flushes on the OpenMAX component ports and, at some
point [3], it disables the egl_render output port (221) and waits for the
buffers currently held by the port to be released. Examining the internal
GstOMX data structure[5] in gdb, there's still one buffer owned by the port
(pending). The OpenMAX IL spec [4] says that the driver should call
EmptyBufferDone or FillBufferDone for each buffer it has to return to us, then
we free the buffer and the port disabling finishes.

The problem is that we're not receiving the Empty/FillBufferDone calls, so the
call to gst_omx_port_wait_buffers_released() on the out_port (ie: the
egl_render 221 port) times out (even if I set to 10 seconds). This causes an
early exit of the set_format function, prevents the deallocation of the buffers
in the video_decode OMX component and the re-enabling of the OMX ports. This
leads to subsequent "Insufficient resources" errors in the involved components
and leaves the pipeline completely unusable (see attached log fragment).

No matter how deep I investgate, I don't understand why this is happening.
However, I've observed that just by preventing the early return after the
waiting for buffers failure, the issue is fixed.


[1] http://home.nouwen.name/RaspberryPi/documentation/ilcomponents/index.html
[2]
http://cgit.freedesktop.org/gstreamer/gst-omx/tree/omx/gstomxvideodec.c#n1819
[3]
http://cgit.freedesktop.org/gstreamer/gst-omx/tree/omx/gstomxvideodec.c#n1902
[4]
https://www.khronos.org/registry/omxil/specs/OpenMAX_IL_1_1_2_Specification.pdf
(diagram on top of page 131)
[5] http://cgit.freedesktop.org/gstreamer/gst-omx/tree/omx/gstomx.h#n207

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