After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 671570 - playbin: video freezes while audio continues normally when you disable subtitle
playbin: video freezes while audio continues normally when you disable subtitle
Status: RESOLVED DUPLICATE of bug 668459
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: High critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-03-07 16:04 UTC by zebul666
Modified: 2013-07-12 14:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
f*** bugzilla that ate my backtrace (32.71 KB, text/plain)
2012-03-29 09:47 UTC, zebul666
Details
gstreamer playbin pipeline (13.47 KB, text/plain)
2012-10-29 15:44 UTC, Sunil Angadi
Details

Description zebul666 2012-03-07 16:04:55 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.

**** ******** ** **** **** *** **** ** ***
Comment 1 Bastien Nocera 2012-03-28 15:16:41 UTC
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!
Comment 2 zebul666 2012-03-28 16:19:59 UTC
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
Comment 3 Bastien Nocera 2012-03-28 21:38:20 UTC
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.
Comment 4 zebul666 2012-03-29 09:40:22 UTC
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 ()

Thread 1 (Thread 0xb627f840 (LWP 17557))

  • #0 __kernel_vsyscall
  • #1 __lll_lock_wait
    from /lib/libpthread.so.0
  • #2 _L_lock_488
    from /lib/libpthread.so.0
  • #3 pthread_mutex_lock
    from /lib/libpthread.so.0
  • #4 g_static_rec_mutex_lock
    at gthread.c line 1450
  • #5 post_activate
    at gstpad.c line 660
  • #6 post_activate
    at gstpad.c line 653
  • #7 gst_pad_activate_push
    at gstpad.c line 963
  • #8 gst_pad_set_active
    at gstpad.c line 718
  • #9 gst_stream_synchronizer_release_stream
    at gststreamsynchronizer.c line 808
  • #10 gst_stream_synchronizer_release_pad
    at gststreamsynchronizer.c line 856
  • #11 gst_element_release_request_pad
    at gstelement.c line 350
  • #12 gst_play_sink_reconfigure
    at gstplaysink.c line 2595
  • #13 gst_play_bin_set_flags
    at gstplaybin2.c line 1398
  • #14 gst_play_bin_set_property
    at gstplaybin2.c line 1904
  • #15 object_set_property
    at gobject.c line 1199
  • #16 g_object_set_valist
    at gobject.c line 1727
  • #17 g_object_set
    at gobject.c line 1833
  • #18 bacon_video_widget_set_subtitle
    at bacon-video-widget-gst-0.10.c line 2763
  • #19 subtitles_changed_callback
    at totem-menu.c line 113
  • #20 g_cclosure_marshal_VOID__OBJECT
    at gmarshal.c line 644
  • #21 g_closure_invoke
    at gclosure.c line 774
  • #22 signal_emit_unlocked_R
    at gsignal.c line 3272
  • #23 g_signal_emit_valist
    at gsignal.c line 3003
  • #24 g_signal_emit
    at gsignal.c line 3060
  • #25 gtk_radio_action_activate
    at gtkradioaction.c line 376
  • #26 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 85
  • #27 g_type_class_meta_marshal
    at gclosure.c line 885
  • #28 g_closure_invoke
    at gclosure.c line 774
  • #29 signal_emit_unlocked_R
    at gsignal.c line 3202
  • #30 g_signal_emit_valist
    at gsignal.c line 3003
  • #31 g_signal_emit
    at gsignal.c line 3060
  • #32 _gtk_action_emit_activate
    at gtkaction.c line 799
  • #33 gtk_action_activate
    at gtkaction.c line 829
  • #34 gtk_real_menu_item_activate
    at gtkmenuitem.c line 1833
  • #35 gtk_check_menu_item_activate
    at gtkcheckmenuitem.c line 503
  • #36 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 85
  • #37 g_type_class_meta_marshal
    at gclosure.c line 885
  • #38 g_closure_invoke
    at gclosure.c line 774
  • #39 signal_emit_unlocked_R
    at gsignal.c line 3202
  • #40 g_signal_emit_valist
    at gsignal.c line 3003
  • #41 g_signal_emit
    at gsignal.c line 3060
  • #42 gtk_widget_activate
    at gtkwidget.c line 6163
  • #43 gtk_menu_shell_activate_item
    at gtkmenushell.c line 1428
  • #44 gtk_menu_shell_button_release
    at gtkmenushell.c line 827
  • #45 gtk_menu_button_release
    at gtkmenu.c line 3476
  • #46 gtk_menu_button_release
    at gtkmenu.c line 3440
  • #47 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 85
  • #48 g_type_class_meta_marshal
    at gclosure.c line 885
  • #49 g_closure_invoke
    at gclosure.c line 774
  • #50 signal_emit_unlocked_R
    at gsignal.c line 3310
  • #51 g_signal_emit_valist
    at gsignal.c line 3013
  • #52 g_signal_emit
    at gsignal.c line 3060
  • #53 gtk_widget_event_internal
    at gtkwidget.c line 6132
  • #54 gtk_propagate_event
    at gtkmain.c line 2614
  • #55 gtk_main_do_event
    at gtkmain.c line 1889
  • #56 _gdk_event_emit
    at gdkevents.c line 71
  • #57 gdk_event_source_dispatch
    at gdkeventsource.c line 360
  • #58 g_main_dispatch
    at gmain.c line 2441
  • #59 g_main_context_dispatch
    at gmain.c line 3011
  • #60 g_main_context_iterate
    at gmain.c line 3089
  • #61 g_main_loop_run
    at gmain.c line 3297
  • #62 gtk_main
    at gtkmain.c line 1362
  • #63 gtk_application_run_mainloop
    at gtkapplication.c line 115
  • #64 g_application_run
    at gapplication.c line 1323
  • #65 main
    at totem.c line 280

Comment 5 zebul666 2012-03-29 09:47:00 UTC
Created attachment 210851 [details]
f*** bugzilla that ate my backtrace

full backtrace for all thread
Comment 6 Bastien Nocera 2012-03-29 09:54:51 UTC
(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.
Comment 7 zebul666 2012-03-29 10:46:15 UTC
well sorry, but the way it displays it let me think that it removed some part of it.
Comment 8 zebul666 2012-03-29 10:50:31 UTC
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
Comment 9 Sunil Angadi 2012-10-29 15:44:09 UTC
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.
Comment 10 Sunil Angadi 2012-10-29 16:01:32 UTC
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).
Comment 11 Tim-Philipp Müller 2012-11-01 22:54:45 UTC
Bug #668459 might be related or the same.
Comment 12 Brendan Long 2013-01-24 17:39:51 UTC
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.
Comment 13 Kostas 2013-04-11 23:07:29 UTC
Same issue with totem 3.6.3
Comment 14 Reynaldo H. Verdejo Pinochet 2013-07-12 14:39:42 UTC
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 ***