omx - in error state at end of video (before EOS)

[Enrique Ocaña González]

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

> > [...] The summary: double check that your sink honors the flush-start 
> > event and that it doesn't hold or leak any egl buffer after flush-starts.
>
> Interesting...  I'm using a pi3 with python with this pipeline:
>      filesrc->decodebin->glimagesink.
> 
> I use set_window_handle from python and am also seeking within my videos.
> the only event I handle is "prepare_window_handle", maybe I need to handle
> some more to clean things up ? Alternately maybe the double free is in
> glimagesink ?

Which version of glimagesink are you using, the one from gst-plugins-gl or the 
one from gst-plugins-bad?

There's a redisplay_texture field in glimagesink which seems to hold the last 
texture received by the sink. In the gst-plugins-gl version, it's only cleared 
[1] on PAUSED --> READY state changes, but not on PAUSED --> PAUSED changes. 
Also there's no code to explicitly handle FLUSH_START events in that gst-
plugins-gl version, so I guess that's done in some base class and nobody 
releases the texture in those cases.

On the other hand, in the gst-plugins-bad version, there's additional support 
for the DRAIN query [2] but still no FLUSH_START management. I'm not fully 
acquainted with the code, but at first sight looks to me that the egl buffer 
which the omxdecoder wants to release so badly is held in redisplay_texture by 
gstglimakesink without permission during flushes, breaking the OMX buffer 
release behaviour.

Cheers.

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

-- 
Enrique Ocaña González