[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 #12 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-01-20 15:07:13 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > True, if the pad is already deadlocked it will not be called, or if it is
> > PAUSED forever :)
> > 
> > Otherwise the IDLE probe will be called even if there never ever is any new
> > data, while the BLOCK probes need actual data flow.
> 
> Doesn't IDLE probe falls back to asynchronous calling if the pad is blocked at
> the moment of add_probe()? If so, then in general case IDLE is nothing better
> than BLOCK, except having even more indeterminity of actual thread executing
> callback procedure.

Yes, but it will be called if there is never ever any data flow anymore on the
pad. A BLOCK not.

> > Well, maybe your block probe was called because of the upstream QoS event...
> > and then you removed the tee branch from there... i.e. the streaming thread of
> > the queue in the worst case.
> 
> So, on higher level of view, does that "if" actually helps GstTq to work the
> right way in general case?
> 
> Would it be right if, before releasing tq pad, application blocks a sinkpad
> connected to tq so that nothing passes?

No, the application should not need to worry about anything and just call
gst_element_release_pad(). And internally you care for all that.

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