GNOME Bugzilla – Bug 683504
playsink: deadlock when disabling subtitles and suboptimal disabling of subtitles
Last modified: 2014-06-10 12:11:48 UTC
Created attachment 223660 [details] [review] playsink: fix text sink getter when default subtitleoverlay is used When the default subtitleoverlay element is used in playsink, the gst_play_sink_get_sink returns NULL when called with GST_PLAY_SINK_TYPE_TEXT. The attached patch returns the subtitleoverlay element instead.
<__tim> I don't know, I don't understand the rationale for that - why would we return an overlay element in get_sink ? you just say what you're doing there, but not why :) <rawoul> this allows changing the overlay properties <rawoul> like 'silent' <rawoul> to toggle subtitles <__tim> you should be able to do that by setting current-text to -1 <rawoul> I just tested and it doesn't seem to work <rawoul> I see [17.165] playbin: <playbin0> Changing current text stream 0 -> -1 <rawoul> but the subtitles are still displayed and 'current-text' is still 0 <__tim> well, that needs fixing then :)
As discussed, the proper way to do toggle subtitles is to add/remove the TEXT flag from playbin/playsink. However removing the flag causes a deadlock in playsink (in 1.0.7 at least): set subtitle track -1 playsink: <playsink> Triggering reconfiguration playsink: <playsink> locking from thread 0x80f48e0 playsink: <playsink> locked from thread 0x80f48e0 playsink: <playsink> unlocking from thread 0x80f48e0 playsink: <playsink> locking from thread 0x7559d5b0 playsink: <playsink> locked from thread 0x7559d5b0 playsink: <playsink:video_sink> Video pad blocked playsink: <playsink> All pads blocked -- reconfiguring playsink: <playsink> Video pad is raw: 1 playsink: <playsink> Audio pad is raw: 0 playsink: <playsink> reconfiguring playsink: <playsink> locking from thread 0x7559d5b0 playsink: <playsink> locked from thread 0x7559d5b0 playsink: <playsink> audio:1, video:1, vis:0, text:0 playsink: <playsink> adding video, raw 1 playsink: <playsink> adding video chain playsink: <playsink> adding audio playsink: <playsink> adding audio chain playsink: <playsink> no vis needed playsink: <playsink> no text needed streamsynchronizer: <streamsynchronizer0> Releasing stream 2 playsink: <playsink> locking from thread 0x74a07690 gst_pad_set_active(pad, false) in streamsynchronizer locks the streaming thread, and playsink is also locked while reconfiguring.
Can you get a backtrace of that deadlock? There are two problems here: a) playsink should just set the silent property on subtitleoverlay if there's already one b) streamsynchronizer should not deadlock when adding/removing subtitleoverlay (it's not entirely clear to me why it deadlocks though)
Here is the backtrace of the locked threads:
+ Trace 231948
Problem in the backtrace is that data flow is happening, causing a pad block while playsink is reconfiguring as result of a pad block, thus we block on the stream lock in two threads. The reconfiguration shouldn't have happened at all before all pads were blocked.
*** Bug 708782 has been marked as a duplicate of this bug. ***
*** Bug 668459 has been marked as a duplicate of this bug. ***
For those looking for a file to reproduce: http://people.collabora.com/~nicolas/Subtitles/Test_AdvancedSubsV2_StandardDef.mkv
(In reply to comment #5) > Problem in the backtrace is that data flow is happening, causing a pad block > while playsink is reconfiguring as result of a pad block, thus we block on the > stream lock in two threads. The reconfiguration shouldn't have happened at all > before all pads were blocked. ... and this might happen because pad probes might be called multiple times. A blocking probe will be called once for every thread that causes a block to happen.
Looking into that
Please test if this fixes all your problems. commit 4dd30bbd166db003f9963f41918b056df338dcf0 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sun Feb 16 15:32:47 2014 +0100 playsink: Only remove the complete text chain if the text pad goes away If the text pads does not go away we just set the overlay to silent, which allows us to immediately re-enable subs later again. However before this change we also released the streamsynchronizer text pads, which deadlocked because there was still dataflow going on. Just do this only if we remove the complete chain. https://bugzilla.gnome.org/show_bug.cgi?id=683504
(y) This has been around for a long time.
*** Bug 727339 has been marked as a duplicate of this bug. ***
*** Bug 700635 has been marked as a duplicate of this bug. ***