[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 #3 from Andrey Utkin <me at andrey-utkin.pp.ua> 2014-01-19 11:07:47 UTC ---
(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.
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;


> Also don't use // comments but /*

Oh damn. Ok, will do.

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


> (In reply to comment #0)
> 
> > The code currently lacks management of inside tee and queues properties. I
> > haven't decided yet how exactly they would be passed through, possibly as two
> > properties "tee-props" and "queue-props" as strings representing a set of
> > key-value pairs.
> 
> 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?

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

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