mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-24 18:51:11 +00:00
9036dc8594
There was a deadlock between a thread changing decodebin/demuxer state from PAUSED to READY, and another thread pushing data when starting. From the stack trace at https://bug741355.bugzilla-attachments.gnome.org/attachment.cgi?id=292471, I deduce the following is happening, though I did not reproduce the problem so I'm not sure this patch fixes it. The streaming thread (thread 2 in that stack trace) takes the demuxer's sink pad's stream lock in gst_ogg_demux_perform_seek_pull and will activate a new chain. This ends up causing the expose lock being taken in _pad_added_cb in decodebin. Meanwhile, a state changed is triggered on thread 1, which takes the expose lock in decodebin in gst_decode_bin_change_state, then frees the previous chain, which ends up calling gst_pad_stop_task on the demuxer's task, which in turn takes the demuxer's sink pad's stream lock, deadlocking as both threads are now waiting for each other. https://bugzilla.gnome.org/show_bug.cgi?id=741355 |
||
---|---|---|
.. | ||
.gitignore | ||
gstdecodebin2.c | ||
gstplay-enum.c | ||
gstplay-enum.h | ||
gstplayback.c | ||
gstplayback.h | ||
gstplaybin2.c | ||
gstplaysink.c | ||
gstplaysink.h | ||
gstplaysinkaudioconvert.c | ||
gstplaysinkaudioconvert.h | ||
gstplaysinkconvertbin.c | ||
gstplaysinkconvertbin.h | ||
gstplaysinkvideoconvert.c | ||
gstplaysinkvideoconvert.h | ||
gstrawcaps.h | ||
gststreamsynchronizer.c | ||
gststreamsynchronizer.h | ||
gstsubtitleoverlay.c | ||
gstsubtitleoverlay.h | ||
gsturidecodebin.c | ||
Makefile.am |