GNOME Bugzilla – Bug 511935
queue2: temp-location locks pipeline
Last modified: 2012-09-24 23:13:17 UTC
Please describe the problem: When a pipeline with queue2's temp-location property is created, playback does not progress from PAUSED. This is always in combination with the decodebin or decodebin2 element. If queue2 is hooked up directly with fakesink, or if an additional queue2 element is added, the pipeline works as normal. Steps to reproduce: gst-launch -v audiotestsrc ! queue2 temp-location=$PWD/tmpfile ! decodebin2 ! fakesink Actual results: The pipeline goes into PAUSE mode, but never goes into PLAYING. Expected results: The following pipeline (without queue2's temp-location property) works: gst-launch -v audiotestsrc ! queue2 ! decodebin2 ! fakesink and also: gst-launch -v audiotestsrc ! queue2 temp-location=$PWD/tmpfile ! fakesink Does this happen every time? Yes. Other information:
typefind tries to get the length from queue2 when going to PAUSED. The source is not yet producing data, queue2 blocks the length query until it receives data -> deadlock.
Makes sense. But why does it only happen when the temp-location property is set?
because with temp-location, queue2 will propose pull based scheduling with random access to the downstream element, which will then respond with doing a seek. This is how typefind currently works (it starts reading data in the state change..). I think I had some solution somewhere but I'll have to check again..
Wim, any news on this?
Doesn't seem to be an issue with 1.0 any longer (presumably because typefind doesn't do typefinding from the state change thread, but asynchronously). If it's still an issue, please re-open.