[Bug 722511] [RFC][PATCH] Introduce 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 #4 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-01-19 11:27:16 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Didn't review it yet but I think it might be beneficial to use IDLE probes
> > here. Should be just an optimization though.
> 
> I don't think so.
> If application developer follows manuals, then it is very probable that
> gst_tq_release_pad() is executed in the inside queue's push thread. And a tee
> pad callback does gst_element_set_state (queue, GST_STATE_NULL), which includes
> joining queue's thread, which would deadlock in case we run it on same thread,
> which is possible with IDLE probe.

Well, the block callbacks will also be called from the streaming thread. So you
have the same problem there. You need to do the shutdown from another thread
that is triggered from the probe callback.

> BTW What do you think about the following place in patch, does it serve right
> purpose?
> 
> +  // Don't execute on any upstream-directed cases
> +  // thus we avoid situation of joining queue's task from itself
> +  if (info->type & (GST_PAD_PROBE_TYPE_DATA_UPSTREAM
> +          | GST_PAD_PROBE_TYPE_QUERY_UPSTREAM))
> +    return ret;

I don't understand why it's necessary but it looks like a hack to me right now.
See what I wrote about the other thread.

> > And when releasing a "tee ! queue" branch you will need to drain it, e.g.
> > EOS event or DRAIN query. Didn't see anything while looking fast over the code.
> 
> I understand how i could send EOS event on queue sinkpad. But i don't
> understand  should i tap on queue srcpad and listen until EOS event exits out
> of it... And how to do that if it is indeed required.
> Regarding DRAIN query, haven't seen its usage at all yet. But found your own
> posting around the internet: "For the DRAIN query, while this in theory is true
> the problem with that is that most elements that actually need to be drained
> don’t implement handling of the query but instead do the same on EOS."

Yes, but queue implements handling of the DRAIN query fortunately :) You have
to intercept the query or the event on the srcpad of the queue, and then from
there shutdown the queue (see above, trigger another thread!)

> > See the GstChildProxy interface. For the queues it might be good to have
> > default settings for newly created queues as part of the "tq" element though.
> 
> Does it mean that no special code is required (because GstTq is a subclass of
> GstBin), and application can listen for signals "child-added", "child-removed"
> and set desired properties in the signal callback?

Yes, might not be the most beautiful API but that's what automatically works
already :)

> > > P. S. How xml doc is generated?
> > 
> > You add stuff to docs/plugins/Makefile.am and then run "make update-docs". Or
> > something like that :)
> 
> Thanks.
> Is that right that GstTq currently does not need to generate any help, because
> it does not provide any special API?

No, it's not properly integrated into the doc build system then. You need to
add it to the Makefile.am, do the make update-docs step, and add things to the
*-sections.txt and add it to the *.sgml file there. It's all not very
straightforward but there's documentation about it somewhere :)

-- 
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.