[Bug 776091] New: omx - in error state at end of video (before EOS)

Wed Dec 14 12:16:16 UTC 2016

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

            Bug ID: 776091
           Summary: omx - in error state at end of video (before EOS)
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: stu.axon at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 341953
  --> https://bugzilla.gnome.org/attachment.cgi?id=341953&action=edit
Deallocate texture in FLUSH_START

I've been playing a video, just before it gets to the end it freezes and I get
the output below.

For now I haven't managed to make some minimal code to reproduce it yet, so
just wondering it is known - similar to the OMX bug mentioned earier ?

https://lists.freedesktop.org/archives/gstreamer-devel/2016-December/061931.html

0:01:32.395974718  7472  0x2364200 ERROR                    omx
gstomx.c:1955:gst_omx_port_wait_buffers_released_unlocked:<omxh264dec-omxh264dec0>
Timeout waiting for egl_render port 221 to release all buffers
0:01:32.396736066  7472  0x2364200 WARN             omxvideodec
gstomxvideodec.c:1620:gst_omx_video_dec_loop:<omxh264dec-omxh264dec0> error:
Unable to reconfigure output port
0:01:32.398866620  7472  0x224f480 ERROR                    omx
gstomx.c:836:gst_omx_component_set_state:<omxh264dec-omxh264dec0> Last
operation returned an error. Setting last_error manually.
0:01:32.398946516  7472  0x224f480 ERROR                    omx
gstomx.c:845:gst_omx_component_set_state:<omxh264dec-omxh264dec0> Error setting
egl_render state from 4 to 3: Insufficient resources (0x80001000)
0:01:32.399041984  7472  0x224f480 ERROR                    omx
gstomx.c:872:gst_omx_component_get_state:<omxh264dec-omxh264dec0> Component
egl_render in error state: Insufficient resources (0x80001000)
0:01:32.399663280  7472  0x224f480 ERROR                    omx
gstomx.c:1467:gst_omx_port_set_flushing:<omxh264dec-omxh264dec0> Component
egl_render is in error state: Insufficient resources (0x80001000)
0:01:32.400010725  7472  0x224f480 ERROR                    omx
gstomx.c:1467:gst_omx_port_set_flushing:<omxh264dec-omxh264dec0> Component
egl_render is in error state: Insufficient resources (0x80001000)
0:01:32.400604053  7472  0x224f480 WARN             omxvideodec
gstomxvideodec.c:2146:gst_omx_video_dec_flush:<omxh264dec-omxh264dec0> Failed
to populate output port: Incorrect state operation (0x80001018)
0:01:32.402515808  7472  0x2364200 ERROR                    omx
gstomx.c:1257:gst_omx_port_acquire_buffer:<omxh264dec-omxh264dec0> Component
egl_render is in error state: Insufficient resources
0:01:32.403512778  7472  0x2364200 WARN             omxvideodec
gstomxvideodec.c:1527:gst_omx_video_dec_loop:<omxh264dec-omxh264dec0> error:
OpenMAX component in error state None (0x00000000)

    El viernes, 9 de diciembre de 2016 13:41:18 (CET) Stuart Axon escribió:

    > I'm pretty sure I'm using the one from gst-plugins-bad (I'm using
gstreamer
    > master, last built about 3 days ago). But not 100% sure, is there a way
to
    > tell ?

    If you're using master, then you're using gst-plugins-bad almost for sure.
    Anyway, it doesn't really mind, as none of the two versions seem to listen
to
    the FLUSH_START event.

    > So maybe I could mitigate this by manually calling drain() if in the
error
    > state or hook into the FLUSH_START?

    My suggestion would be to focus on FLUSH_START instead of reacting in the
    error state. In my experience, when "Insufficient resources" happens, it's
too
    late to revert to a working state again.

    So, what I would do would be to touch gst_glimage_sink_event()[1], adding a
    case for FLUSH_START. There you could do the same as the DRAIN query
does[2]
    (copy-paste or refactor into a common function called from both places).
Make
    sure that you don't return inside the case, so the code flow continues and
    ends up calling to the ancestor class method to process the event[3]. That
    last part is important for the right operation of the element.

    > I haven't seen the error in dispmanx-gst-play, however, my player is a
bit
    > more complex - I update the play state (seek, or try and change file) in
    > gobject timer, from data I get on the network. S++

    I haven't looked in deep how dispmanx-gst-play works, so I can't give an
    opinion about why things work there. Maybe a different sink is used (one
which
    doesn't hold EGL buffers for itself on flush), I don't know.

    Another think I forgot: check that your Raspberry has enough graphics
memory
    configured. Assuming you're using raspbian: sudo raspi-config, advanced
    options, memory split. Use some higher value such as 128.

    In any case, I hope the suggestions help you to fix the issue. :-)

    Cheers.

    [1] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/
    gstglimagesink.c?id=1.10.2#n1023

    [2] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/
    gstglimagesink.c?id=1.10.2#n1118

    [3] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/
    gstglimagesink.c?id=1.10.2#n1069

    -- 
    Enrique Ocaña González
    _______________________________________________
    gstreamer-devel mailing list
    [hidden email]
    https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Free forum by Nabble     Disable Popup Ads | Edit this page

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