GNOME Bugzilla – Bug 671570
playbin: video freezes while audio continues normally when you disable subtitle
Last modified: 2013-07-12 14:39:42 UTC
To reproduce: 1. Open a video with a srt subtitle of the same name alongside that video file 2. Wait until some subtitle are displayed or skip to later in the video 3. Go to the menu View > Subtitles. Choose None 4. The video image is freezing to the latest image displayed when you disbled the subtitle while the audio is still playing normally 5. One can't close or interact at all with totem (GUI freeze). You have to kill it. **** ******** ** **** **** *** **** ** ***
Thanks for taking the time to report this bug. Without a stack trace from the hang it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
how am i suppose to give a stack trace if it does not crash ? I am using nouveau driver nouveau-dri 8.0.2-1 xf86-video-nouveau 0.0.16_git20120210-1
By attaching to the running process with gdb: http://live.gnome.org/GettingTraces/Details#Obtaining_a_stack_trace_using_GDB_with_a_running_program Press Ctrl+C after typing "cont" as per the instructions.
well it's the same if I run totem within gdb and press ctrl-c after the bug happened, right ? I don't see how you will pinpoint the problem from the backtrace but here it is Starting program: /usr/bin/totem [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". [New Thread 0xb5effb40 (LWP 17560)] [New Thread 0xb428bb40 (LWP 17561)] [New Thread 0xb19e6b40 (LWP 17562)] [Thread 0xb19e6b40 (LWP 17562) exited] [New Thread 0xb19e6b40 (LWP 17563)] [New Thread 0xb00b0b40 (LWP 17565)] [New Thread 0xaf898b40 (LWP 17566)] [New Thread 0xab015b40 (LWP 17567)] [New Thread 0xaa814b40 (LWP 17568)] [New Thread 0xa9fbcb40 (LWP 17569)] [New Thread 0xa86ffb40 (LWP 17570)] [New Thread 0xa7efeb40 (LWP 17571)] [New Thread 0xa76fdb40 (LWP 17572)] [New Thread 0xa64b8b40 (LWP 17573)] Program received signal SIGINT, Interrupt. 0xb7fdd424 in __kernel_vsyscall ()
+ Trace 229972
Thread 1 (Thread 0xb627f840 (LWP 17557))
Created attachment 210851 [details] f*** bugzilla that ate my backtrace full backtrace for all thread
(In reply to comment #5) > Created an attachment (id=210851) [details] > f*** bugzilla that ate my backtrace It didn't: https://bugzilla.gnome.org/page.cgi?id=trace.html&trace_id=229972 That trace is actually searchable, unlike the attachment you just added. And keep that sort of language out of Bugzilla too. Looks like a GStreamer bug.
well sorry, but the way it displays it let me think that it removed some part of it.
using gstreamer0.10 0.10.36-1 gstreamer0.10-bad 0.10.23-1 gstreamer0.10-bad-plugins 0.10.23-1 gstreamer0.10-base 0.10.36-1 gstreamer0.10-base-plugins 0.10.36-1 gstreamer0.10-ffmpeg 0.10.13-1 gstreamer0.10-good 0.10.31-1 gstreamer0.10-good-plugins 0.10.31-1 gstreamer0.10-pitfdll 0.9.1.1-2 gstreamer0.10-python 0.10.22-1 gstreamer0.10-ugly 0.10.19-1 gstreamer0.10-ugly-plugins 0.10.19-1 gstreamermm 0.10.10-1 totem 3.2.2-1
Created attachment 227547 [details] gstreamer playbin pipeline For the file I am playing attached is the pipeline. Here are the observations: The portion of interest is path uridecobin1--inputselector--streamsync--subqueue (filesrc,reading the subtitle file, is pushing the data to subqueue) and elements marked with * are threads. Actually the video playback is not stuck forever but for about 6 mins(5:37 to be precise), thereafter playback resumes. Here is what is happening. a. Filesrc is pushing data to subqueue but subqueue seems to be full hence this path is blocked and holds streamsynchronizer's 'pad stream lock' associated with text(sink pad). [Independently, as an experiment, I put a breakpoint at gst_base_src_loop at start-up and let it run freely with subtitles enabled. The breakpoint gets hit 5 times at start-up and thereafter it gets hit at time 5:37; till then this path is blocked]. b. Now, when subtitle are disabled main function tries to release streamsynchronizer's pad associated with text and gets blocked since 'pad stream lock' is being taken as mentioned in point 'a'. c. Video is not being played because actual video rendering is being done by main function(i.e main function has set the video sink(gstcluttersink) to playbin2. Below given is piece of code which is waking up the main loop for rendering a frame. static void clutter_gst_source_push (ClutterGstSource *gst_source, GstBuffer *buffer) { ClutterGstVideoSinkPrivate *priv = gst_source->sink->priv; g_mutex_lock (gst_source->buffer_lock); if (gst_source->buffer) gst_buffer_unref (gst_source->buffer); gst_source->buffer = gst_buffer_ref (buffer); g_mutex_unlock (gst_source->buffer_lock); g_main_context_wakeup (priv->clutter_main_context); } Cross checked that 'priv->clutter_main_context' corresponds to main function main loop context. And finally video starts playing back after about 5 mins when the path mentioned in point 'a' releases the 'stream lock' for pad that is being released when subs get disabled. All in all, seems like it is the problem with 'buffer size' being configured for filesource in uridecodebin1/subqueue getting full i.e subqueue getting drained at a slower rate and subtitle path getting blocked for about 5 minutes after each time it reads the subtitle file.
I tried to set blocksize of gstbase source to 100 and I am able to disable subtitles without blocking the video, however if the subtitles start little bit late(e.g: once the credits are over, if they are appearing at the start of clip), then video is blocked till a buffer(worth 100 bytes) gets released. On the other hand, if I keep trying disable/enable of subtitle multiple times at some point no effect is observed w.r.t subtitle appearing/disappearing -- filesrc is in paused state :(, while the rest of things seem to be happening fine in playbin(flags property(GST_PLAY_FLAG_TEXT) is being set appropriately).
Bug #668459 might be related or the same.
I had a problem similar to this on 0.10.36, where switching audio, video or text tracks in playbin2 caused the video to hang for a couple minutes (playback continues, but it keeps displaying the same frame). If I build against the HEAD revision of 0.10, the problem goes away. It might be worth checking if this works for you.
Same issue with totem 3.6.3
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 668459 ***