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

[GStreamer (GNOME Bugzilla)]

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

Matthew Waters (ystreet00) <ystreet00 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #16 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
(In reply to Stuart Axon from comment #11)
> @ystreet00 I'm up for trying to find out more about how dispmanx behaves,
> but no idea where to get help + feedback with for the RPI userland though.

The best option would be something around the community at
https://github.com/raspberrypi

(In reply to Stuart Axon from comment #14)
> I'd like to have a proper solution to be able have this work:
> 
> filesrc->decodebin->glimagesink
> 
> - set window handle
> - window size set during prepare window handle
> 
> on eos:
> 
> - set pipeline state to READY
> - set filesrc.location to new file
> - set pipeline state to PLAYING
> 
> pipeline plays new content, using existing in window handle
> 
> Any idea where I would need to start, or if the premise is even correct ?

That's exactly what's meant to happen.

(In reply to Stuart Axon from comment #15)
> There is definitely a memory leak (or something very like it).

This seems to be intermittent.  Sometimes with:

GST_TRACERS=leaks GST_DEBUG=3,*TRACER*:7 gst-play-1.0 /path/to/file

The gl bufferpool (and all associated objects aren't freed).

However, with the linked slideshow.py script, everything is leaked (when
modified to call Gst.deinit() in the appropriate places.

I would suggest writing your example in C so you know exactly where and when
your references are and are taken/given and so we can rule out reference issues
with python/gobject-introspection/etc.

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