omx - in error state at end of video (before EOS)
Stuart Axon
stuaxo2 at yahoo.com
Fri Dec 9 13:41:18 UTC 2016
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 ?
So maybe I could mitigate this by manually calling drain() if in the error state or hook into the FLUSH_START ? - this seems a bit vague, as I haven't looked at these parts of Gstreamer yet.
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++
On Friday, December 9, 2016 12:26 PM, Enrique Ocaña González <eocanha at igalia.com> wrote:
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
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161209/1dbbdc6c/attachment.html>
More information about the gstreamer-devel
mailing list