GNOME Bugzilla – Bug 727339
playbin: changing subtitles in MP4 video freezes totem
Last modified: 2014-05-01 11:25:33 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
Please attach a backtrace of the hang as well as a test file.
steps to reproduce: 1) play some mp4 2) open arbitrary srt file while playing 3) switch to "None" video hangs. bt:
+ Trace 233467
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?
(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.
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:
+ Trace 233468
Thread 24 (Thread 0x7fff73fff700 (LWP 5096))
Thread 13 (Thread 0x7fffaa191700 (LWP 5085))
i run a freshly caught totem from git on gnome 3.12 with gstreamer 1.2.3. @michael, i run intel hd 4000 graphics
*** Bug 728572 has been marked as a duplicate of this bug. ***
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.
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 ***