[Bug 797147] queue deadlocks if it is connected to the second pad of a tee

[GStreamer (GNOME Bugzilla)]

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

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |t.i.m at zen.co.uk

--- Comment #2 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
This is expected behaviour and not a bug, and it is not the queue that
deadlocks.

You need a queue after a tee for each downstream branch. (The fact that it
works with only one queue is basically coincidence and assumes the pads will
always be iterated in that order.)

The reason it deadlocks if you go straight from tee to fakesink for the first
pad is because that's the way GStreamer's preroll mechanism works.

tee will push buffers on each pad from the upstream streaming thread. When it
pushes directly to fakesink, fakesink will say "oh good, I'm prerolled now" and
block the streaming thread until the pipeline goes to PLAYING state.

Now that streaming thread is blocked/stuck in the fakesink, it can't continue
to push buffers to the second fakesink, but the pipeline is waiting for the
second fakesink to preroll (get a buffer), and it will wait forever, unless you
set async=false on the second fakesink.

This is basically a pipeline construction bug :)

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