GNOME Bugzilla – Bug 673604
Seek without flush flag in paused state cause deadlock
Last modified: 2012-04-07 13:45:12 UTC
Created attachment 211427 [details] Sample backtrace with ogg I found that seeking without the flush flag, while in paused state will cause deadlock with most demuxer (tested ogg, avi, flv and qt). Found in 0.10, but reproduce in 0.11 also. Step to reproduce: - compile gst-plugins-base examples - run the seek example with a muxed file (if .11 now in playback folder) - pause the stream - uncheck flush flag - seek The demuxer will try and stop the task on the pad, which will wait for the streaming lock to be released. But that never happens because we are not playing. It seems like seeking without flushing in paused state is not really possible, but we should probably not deadlock, but handle it correctly.
That's expected, non-flushing seeks must be used with caution. And yes, they don't work in PAUSED state (because non-flushing seeks wait until all pending data is played before doing the seek... and obviously that takes forever in PAUSED).
Just to expand on that, the main use case for non-flushing seeks is looping, in which case you would do a SEGMENT seek and wait for the SEGMENT_DONE message on the bus, which the parser/demuxer driving the pipeline will post when it has finished streaming (instead of pushing an EOS event downstream). What's your use case here?