GNOME Bugzilla – Bug 769212
Pipeline state change ( PLAYING -> PAUSED ) hung on the RPi.
Last modified: 2018-05-07 15:50:45 UTC
I am experiencing some issues with PLAYING -> PAUSED state changes especially when trying to perform the state change in a synchronous way. The issue seems to appear also when trying the async way but less frequently. More specifically the pipeline will just hung waiting for playbinsink to commit the state change which never seems to happen in the end. My pipeline is playbin-based with a bin connected that contains an appsink and glupload/glcolorconvert for the texture handling. Going through the log from what I understand all child elements are successfully changing state but playbinsink seems to refuse to do that.. Same code works properly on OS X and Linux desktop with the same versions of gst and plugins. Attached is a log output configured with GST_DEBUG=6. Thanks for any hints Petros
Can you get a backtrace of all threads when it hangs? Also which version of GStreamer and the plugins are you using?
Created attachment 332197 [details] Debug log with GST_DEBUG=6
Created attachment 332198 [details] Debug log with GST_DEBUG=6 ( part B )
I had to break down the log file to be able to upload it. Apologies for that. I am using 1.9.1.1 ( Basically master from last week ). I will get back with a backtrace from all threads.
Created attachment 332204 [details] Threads backtrace This is as far as I can get before gdb quitting on me..
It might work better after installing debug symbols for libc6 and glib
Debug symbols for libc6 are already installed. This does not seem to be the case for glib but apt is unable to locate and install libglib2.0-0-dbg on the RPi.
This could be that some parts of the pipeline don't have quite enough buffering to allow for max interleaving.
+ Trace 236507
Thread 10 (Thread 0x70dff3c0 (LWP 2736))
I'm experiencing the same bug with the latest gstreamer source code. For me I found a workaround to not completely stall the whole program by adding a timeout to gst_element_get_state. After the call timed out, the program continues and goes to PAUSE state just fine. Using this makes it work on the RPI but it's an asynchronous behavior and comes with other problems for me. By the way I'm using the same pipeline as Petros.
Hey all, just to add my findings on this bug on RPi and Jessie. I also saw that a similar bug was reported here: https://bugzilla.gnome.org/show_bug.cgi?id=770420 I'm also struggling since over a month to get it right. I'm using gstreamer 1.9.1 and gst-omx 1.9.1 uninstalled environment. I extensively tested the testegl example found in gst-omx repo and the bug never happened there. Then I was looking for a bug on the player implementation on our side and it looks like as soon as I use the provided GstSample from the appsink callback (just holding a pointer, with proper unrefing is enough ) it hangs sometime after playback. If I don't use the GstSample and just unref it in the callback. It runs forever. So since the only difference between testegl, our implementation (Cinder framework)and the other bug report (Openframewokrs) is, that testegl is not using appsink while the others do, I'm wondering if someone has a new clue and what could be the problem here. Thanks Patrick
For reference here you can find the player implementation ( work in progress ) https://github.com/PetrosKataras/Cinder/blob/gst-player-refactor-and-osx-support/src/cinder/linux/GstPlayer.cpp Best, Petros
It sounds like you're keeping a reference to the buffer for too long, essentially starving the gst-omx buffer pool. You need to make sure that this never happens from the application side.