[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 #18 from Andrey Utkin <me at andrey-utkin.pp.ua> 2014-01-22 10:26:48 UTC ---
(In reply to comment #17)
> (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?

No, because tee srcpad is inside tq and is unavailable at application context.
And i don't like the idea that application needs to find internal tee, and
manage probes on its pads, and manage queue elements. So, we want tq to behave
in opaque way and be managable via gst_element_release_request_pad(). For this,
the pad releasing operation can only start with blocking probe on tq srcpad and
executing  gst_element_release_request_pad(tq, pad) from this probe callback,
then following a procedure i described in comment #15 and which is currently
implemented in a patch.

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