[Bug 722511] tq: tee element with embedded queue elements on srcpads

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=722511
  GStreamer | gst-plugins-bad | git

--- Comment #17 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-01-22 09:18:50 UTC ---
(In reply to comment #15)

> Assume the application wants to release a requested pad of tq.
> It is done my setting up a probe callback that does
> gst_element_release_request_pad (tq, pad) and returns ...REMOVE.

A probe on which pad? When the application wants to remove the request pad of
tq, you could just:

1) set up a block (data-downstream) on the tee srcpad
2) from there set up a query probe on the queue srcpad
3) do the drain query and drop it in the query probe
4) release the tee srcpad, shutdown the queue

Adding the IDLE probe to the mix (for 1)) will require you to decouple 3/4 but
doing them in another thread, and from that thread you would remove the probe
created in 1.

Does that make sense?

> The most probable thread on which this callback could execute, if all is linked
> and playing, is the pushing thread of queue behind the subject tq pad.

It's going to be the streaming thread upstream of the tee... or for upstream
events like QoS (on which you should not block really!) the streaming thread of
the queue srcpad.

> So in gst_tq_release_pad(), we have to account this, and avoid doing
> ...set_state (queue, ...NULL) straight in the procedure. Instead, what is
> currently implemented is doing it from internal tee's srcpad probe.
> I think there's no conceptual problem at this point.
> But, as you have confirmed my observation, in this environment the callback can
> be executed by upstream-directed flow, exactly the tee's srcpad probe callback
> in this case. And this can result in tee srcpad probe callback being executed
> by the queue thread, and doing ...set_state (queue, ...NULL) will deadlock or
> at last give a critical assertion warning.
> 
> I haven't found a possibility to exclude upstream-directed cases by bitmask
> passed to ...add_probe(), so i have excluded these cases as "if" in the
> procedure itself.

Try with GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.