GNOME Bugzilla – Bug 453369
Deadlock involving preroll queue filling
Last modified: 2009-04-15 22:08:54 UTC
Steps to reproduce: 1. Use a playbin to play a file with more than 1 stream. 2. Enact lots of state changes. 3. Goto 2. See attached test program to reproduce easily. Stack trace: Starting program: /home/tim/tmp/gst-test file:///home/tim/Desktop/sync_s.avi [Thread debugging using libthread_db enabled] [New Thread -1213531600 (LWP 15586)] 0 [New Thread -1215665264 (LWP 15590)] [New Thread -1224623216 (LWP 15591)] [New Thread -1233171568 (LWP 15592)] EOS 1 EOS 2 EOS 3 Program received signal SIGINT, Interrupt. [Switching to Thread -1213531600 (LWP 15586)] 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt
+ Trace 145451
Other information:
Created attachment 91099 [details] Simple test application that may be used to reproduce the bug
Created attachment 91100 [details] Media used in combination with the test program to produce stack trace in bug report It seems any file with more than 1 stream causes the deadlock, but this is the particular file used to reproduce the stack trace as seen in the bug report.
this is quite a special case of a sink that cannot preroll because a queue is filled. The reason being that the sinks try to consume as much data as quickly as possible, which might cause one of the queue to fill up. Not quite sure how to solve this except for growing the queue even more (there must be a limit, though). It's definatly not a bug in the state changes.
Increasing DEFAULT_QUEUE_SIZE and the "max-size-bytes" proprty on the preroll queue in gstplaybasebin.c tends to reduce the occurrence of this bug. Increasing the sizes by a factor of about 100 seems to more or less prevent it, but obviously it uses a silly amount of memory as a result (and doesn't actually fix the bug). g_object_set (G_OBJECT (preroll), "max-size-buffers", 0, "max-size-bytes", ((type == GST_STREAM_TYPE_VIDEO) ? 25 : 1) * 1024 * 1024, "max-size-time", play_base_bin->queue_size, NULL); For what it's worth the signal handler queue_overrun as set by overrun_sig = g_signal_connect (G_OBJECT (preroll), "overrun", G_CALLBACK (queue_overrun), play_base_bin); in the same function doesn't seem to get called when the queue fills. I'm not sure if this is a problem? I'm fairly desperate to get this fixed; if there is any direction you can give me toward resolving this I'd really appreciate it.
Created attachment 91297 [details] FLV which when used with "gst-launch playbin uri=..." exhibits the lock
I've managed to reproduce this without using fakesinks or any other weird usage patterns. It's just using "gst-launch playbin uri=..." with the attached FLV. It normally takes a few attempts to reproduce; usually about 5 or 6. Below is a stacktrace at the point of locking. Starting program: /home/tim/sources/gstreamer/head/gstreamer/tools/.libs/lt-gst-launch-0.10 playbin uri=file:///home/tim/Desktop/caddon/caddon.flv [Thread debugging using libthread_db enabled] [New Thread -1212740880 (LWP 5180)] Setting pipeline to PAUSED ... [New Thread -1218626672 (LWP 5183)] Pipeline is PREROLLING ... [New Thread -1227236464 (LWP 5184)] [New Thread -1235629168 (LWP 5185)] [New Thread -1246651504 (LWP 5188)] [New Thread -1256588400 (LWP 5190)] [New Thread -1264981104 (LWP 5191)] Program received signal SIGINT, Interrupt. [Switching to Thread -1212740880 (LWP 5180)] 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt
+ Trace 146103
Thread 5 (Thread -1246651504 (LWP 5188))
Thread 3 (Thread -1227236464 (LWP 5184))
Note that the FLV is a 512Kb truncation of a larger one. I would upload the full thing but it's 15Mb; probably a bit big for bugzilla. The behaviour with respect to this bug appears to be the same however, regardless of the length used.
I'm having the same issue when I use my custom element in some application like Totem. Somehow I'm never able to switch to back PLAYING again. It seems some sink stays ASYNC.
So, umm, this is quite old. Not sure what to do about this. Closing as OBSOLETE for now, since there have been quite a few fixes even for decodebin/playbin/queue since then. It plays fine with playbin and playbin2 for me with current git versions of things. Please re-open if you think it's still an issue, but be advised that there are known issues with decodebin/playbin which are only fixed in decodebin2/playbin2.