GNOME Bugzilla – Bug 753080
queue2: Doesn't push the flush stop on its thread
Last modified: 2018-11-03 12:29:24 UTC
I have this backtrace where a flush stop event from a demuxer ends push making a stick stream-start be pushed down and then get's stuck in playsink's pad probe. So it causes a deadlock. I'm attaching a patch that just makes queue2 put the flush-stop in the queue, but I guess the other option would be to make playsink's probe drop stick events and just wait for buffer/gap before continuing. My test is: GST_DEBUG=2 GST_GL_XINITTHREADS=1 DISPLAY=:1 GST_VALIDATE_SCENARIO=change_state_intensive gdb --args gst-validate-1.0 playbin uri=http://127.0.0.1:8079/defaults/ogg/vorbis_theora.1.ogg audio-sink='fakesink sync=true' video-sink='fakesink sync=true' --set-media-info "/home/ocrete/gst-validate/gst-integration-testsuites/medias/defaults/online-streams-infos/http/vorbis_theora.1.ogg.stream_info Here is the stack trace:
+ Trace 235312
Thread 5 (Thread 0x7fffd71a3700 (LWP 2553))
Created attachment 308497 [details] [review] queue2: Forward flush stop through the queue.
Review of attachment 308497 [details] [review]: This breaks qtdemux playback, so it can't be merged as-is..
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/126.