[Bug 746808] New: Queue with min-threshold stalls dynamic pipeline

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=746808

            Bug ID: 746808
           Summary: Queue with min-threshold stalls dynamic pipeline
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: knorr.jesper at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 300348
  --> https://bugzilla.gnome.org/attachment.cgi?id=300348&action=edit
Test application that stalls the pipeline

I'm not 100% sure whether this is a bug or a mistake on my part. I have
attached the test application I'm using.

I have a pipeline that looks like this

audiotestsrc is-live=true ! queue min-threshold-time=3s ! fakesink

Running that pipeline works as I expect. The pipeline position stays at 0 while
the level in the buffer is filling to 3s, and then the pipeline position starts
to increase.

Now, I want to change the sink at some point, keeping the cached data in the
queue. 8 seconds after starting the pipeline, I add a blocking probe to the
srcpad of the queue.

In the probe callback I do the following:
1. Set the state of the sink to NULL
2. Remove the sink from the pipeline
3. Add a second fakesink element to the pipeline
4. Link the queue and the second fakesink
5. Sync the state of the second fakesink to the pipeline

I would expect the pipeline to continue running with the new sink in place.

What I'm actually seeing is that the sink is prerolled with a single buffer,
and then nothing more happens. The queue is not getting any buffers even though
all elements in the pipeline reports as PLAYING, if I save a dot graph.

If I don't set min-threshold on the queue, data is flowing after I have changed
the sink.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.