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 727339 - playbin: changing subtitles in MP4 video freezes totem
playbin: changing subtitles in MP4 video freezes totem
Status: RESOLVED DUPLICATE of bug 683504
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.x
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 728572 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-03-30 11:13 UTC by Michael Monreal
Modified: 2014-05-01 11:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Monreal 2014-03-30 11:13:39 UTC
Changing subtitles in MKV files works fine in totem 3.12. However, changing subtitles (for example: setting to "none") in MP4 files freezes totem. 

It does not matter if playback is paused: if you change the subtitle while paused and then resume playback, it will still freeze after about a second.

My test file (x264 video, aac audio and srt subtitles) was created using MP4Box
Comment 1 Bastien Nocera 2014-03-30 20:05:08 UTC
Please attach a backtrace of the hang as well as a test file.
Comment 2 Torsten Scholak 2014-04-13 02:41:49 UTC
steps to reproduce:
1) play some mp4
2) open arbitrary srt file while playing
3) switch to "None"

video hangs. bt:

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 135
  • #1 _L_lock_1060
    from /lib64/libpthread.so.0
  • #2 __GI___pthread_mutex_lock
    at pthread_mutex_lock.c line 85
  • #3 gst_play_sink_navigation_send_event
    from /usr/lib64/gstreamer-1.0/libgstplayback.so
  • #4 bacon_video_widget_motion_notify
    from /usr/lib64/libtotem.so.0
  • #5 _gtk_marshal_BOOLEAN__BOXEDv
    at gtkmarshalers.c line 130
  • #6 _g_closure_invoke_va
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/gobject/gclosure.c line 831
  • #7 g_signal_emit_valist
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/gobject/gsignal.c line 3215
  • #8 g_signal_emit
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/gobject/gsignal.c line 3363
  • #9 gtk_widget_event_internal
    at gtkwidget.c line 7228
  • #10 gtk_widget_event
    at gtkwidget.c line 6890
  • #11 propagate_event_up
    at gtkmain.c line 2406
  • #12 propagate_event
    at gtkmain.c line 2514
  • #13 gtk_main_do_event
    at gtkmain.c line 1735
  • #14 gdk_event_source_dispatch
    at gdkeventsource.c line 364
  • #15 g_main_dispatch
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/gmain.c line 3064
  • #16 g_main_context_dispatch
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/gmain.c line 3663
  • #17 g_main_context_iterate
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/gmain.c line 3734
  • #18 g_main_context_iteration
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/gmain.c line 3795
  • #19 g_application_run
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/gio/gapplication.c line 2114
  • #20 main

Comment 3 Michael Monreal 2014-04-13 07:32:56 UTC
Thanks Torsten! Sadly I did not have time create a backtrace yet. But what is worth mentioning that I was so far unable to reproduce this on my other system. The systems differ in graphics hardware, the one where I run into this is using the NVidia binary driver.

@Torsten: what graphics hardware and driver were you using?
Comment 4 Bastien Nocera 2014-04-13 10:52:22 UTC
(In reply to comment #2)
> steps to reproduce:
> 1) play some mp4
> 2) open arbitrary srt file while playing
> 3) switch to "None"
> 
> video hangs. bt:

Hmm. This isn't the same bug that was mentioned in comment 1. Comment 1 is clearly about builtin subtitles (built into the video file itself). Your example is about using external subtitles. Furthermore the backtrace only contains one thread, which makes checking where the hang/deadlock might have happened kind of difficult.
Comment 5 Torsten Scholak 2014-04-14 00:22:20 UTC
I'm not so sure that Michael was explicitly talking about built-in subtitles. In any case, what I have found could be well related. Here's a bt of all threads:

Thread 24 (Thread 0x7fff73fff700 (LWP 5096))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 135
  • #1 _L_lock_1060
    from /lib64/libpthread.so.0
  • #2 __GI___pthread_mutex_lock
    at pthread_mutex_lock.c line 85
  • #3 sinkpad_blocked_cb
    from /usr/lib64/gstreamer-1.0/libgstplayback.so
  • #4 probe_hook_marshal
    from /usr/lib64/libgstreamer-1.0.so.0
  • #5 g_hook_list_marshal
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/ghook.c line 672
  • #6 do_probe_callbacks
    from /usr/lib64/libgstreamer-1.0.so.0
  • #7 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #8 gst_proxy_pad_chain_default
    from /usr/lib64/libgstreamer-1.0.so.0
  • #9 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #10 gst_selector_pad_chain
    from /usr/lib64/gstreamer-1.0/libgstcoreelements.so
  • #11 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #12 gst_proxy_pad_chain_default
    from /usr/lib64/libgstreamer-1.0.so.0
  • #13 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #14 gst_proxy_pad_chain_default
    from /usr/lib64/libgstreamer-1.0.so.0
  • #15 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #16 gst_audio_decoder_push_forward
    from /usr/lib64/libgstaudio-1.0.so.0
  • #17 gst_audio_decoder_output
    from /usr/lib64/libgstaudio-1.0.so.0
  • #18 gst_audio_decoder_finish_frame
    from /usr/lib64/libgstaudio-1.0.so.0
  • #19 gst_faad_handle_frame
    at gstfaad.c line 799
  • #20 gst_audio_decoder_push_buffers
    from /usr/lib64/libgstaudio-1.0.so.0
  • #21 gst_audio_decoder_chain_forward
    from /usr/lib64/libgstaudio-1.0.so.0
  • #22 gst_audio_decoder_chain
    from /usr/lib64/libgstaudio-1.0.so.0
  • #23 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #24 gst_base_parse_push_frame
    from /usr/lib64/libgstbase-1.0.so.0
  • #25 gst_base_parse_chain
    from /usr/lib64/libgstbase-1.0.so.0
  • #26 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #27 gst_multi_queue_loop
    from /usr/lib64/gstreamer-1.0/libgstcoreelements.so
  • #28 gst_task_func
    from /usr/lib64/libgstreamer-1.0.so.0
  • #29 g_thread_pool_thread_proxy
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/gthreadpool.c line 307
  • #30 g_thread_proxy
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/gthread.c line 764
  • #31 start_thread
    at pthread_create.c line 308
  • #32 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 113

Thread 13 (Thread 0x7fffaa191700 (LWP 5085))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 135
  • #1 _L_lock_1060
    from /lib64/libpthread.so.0
  • #2 __GI___pthread_mutex_lock
    at pthread_mutex_lock.c line 85
  • #3 gst_pad_activate_mode
    from /usr/lib64/libgstreamer-1.0.so.0
  • #4 gst_pad_set_active
    from /usr/lib64/libgstreamer-1.0.so.0
  • #5 gst_stream_synchronizer_release_pad
    from /usr/lib64/gstreamer-1.0/libgstplayback.so
  • #6 sinkpad_blocked_cb
    from /usr/lib64/gstreamer-1.0/libgstplayback.so
  • #7 probe_hook_marshal
    from /usr/lib64/libgstreamer-1.0.so.0
  • #8 g_hook_list_marshal
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/ghook.c line 672
  • #9 do_probe_callbacks
    from /usr/lib64/libgstreamer-1.0.so.0
  • #10 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #11 gst_proxy_pad_chain_default
    from /usr/lib64/libgstreamer-1.0.so.0
  • #12 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #13 gst_selector_pad_chain
    from /usr/lib64/gstreamer-1.0/libgstcoreelements.so
  • #14 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #15 gst_proxy_pad_chain_default
    from /usr/lib64/libgstreamer-1.0.so.0
  • #16 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #17 gst_proxy_pad_chain_default
    from /usr/lib64/libgstreamer-1.0.so.0
  • #18 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #19 gst_video_decoder_clip_and_push_buf
    from /usr/lib64/libgstvideo-1.0.so.0
  • #20 gst_video_decoder_finish_frame
    from /usr/lib64/libgstvideo-1.0.so.0
  • #21 gst_ffmpegviddec_video_frame
    from /usr/lib64/gstreamer-1.0/libgstlibav.so
  • #22 gst_ffmpegviddec_frame
    from /usr/lib64/gstreamer-1.0/libgstlibav.so
  • #23 gst_ffmpegviddec_handle_frame
    from /usr/lib64/gstreamer-1.0/libgstlibav.so
  • #24 gst_video_decoder_decode_frame
    from /usr/lib64/libgstvideo-1.0.so.0
  • #25 gst_video_decoder_chain_forward
    from /usr/lib64/libgstvideo-1.0.so.0
  • #26 gst_video_decoder_chain
    from /usr/lib64/libgstvideo-1.0.so.0
  • #27 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #28 gst_base_transform_chain
    from /usr/lib64/libgstbase-1.0.so.0
  • #29 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #30 gst_base_parse_push_frame
    from /usr/lib64/libgstbase-1.0.so.0
  • #31 gst_base_parse_chain
    from /usr/lib64/libgstbase-1.0.so.0
  • #32 gst_pad_push_data
    from /usr/lib64/libgstreamer-1.0.so.0
  • #33 gst_multi_queue_loop
    from /usr/lib64/gstreamer-1.0/libgstcoreelements.so
  • #34 gst_task_func
    from /usr/lib64/libgstreamer-1.0.so.0
  • #35 g_thread_pool_thread_proxy
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/gthreadpool.c line 307
  • #36 g_thread_proxy
    at /var/tmp/portage/dev-libs/glib-2.40.0/work/glib-2.40.0/glib/gthread.c line 764
  • #37 start_thread
    at pthread_create.c line 308
  • #38 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 113

i run a freshly caught totem from git on gnome 3.12 with gstreamer 1.2.3.

@michael, i run intel hd 4000 graphics
Comment 6 Bastien Nocera 2014-04-25 08:58:33 UTC
*** Bug 728572 has been marked as a duplicate of this bug. ***
Comment 7 Tim-Philipp Müller 2014-04-25 22:31:05 UTC
Has anyone tried this with git? I haven't seen this for a while, I thought it got fixed some time ago, but not sure if it was picked into 1.2.
Comment 8 Sebastian Dröge (slomo) 2014-05-01 11:25:33 UTC
I think the second trace in comment 5 is a duplicate of bug #683504 , which is fixed in 1.2.4. The first trace only contains one thread but we would need all.

Closing as a duplicate for now unless someone can reproduce with 1.2.4 and/or git master.

*** This bug has been marked as a duplicate of bug 683504 ***