[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 #13 from Andrey Utkin <me at andrey-utkin.pp.ua> 2014-01-20 15:16:17 UTC ---
(In reply to comment #12)
> (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.

What about a situation that direct synchronous execution is not performed
because the pad is blocked by some data flow, and asynchronous execution does
not take place also because that data flow act which prevented synchronous
execution was LAST on that pad?

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

Well, the context was that this "if" is internal to GstTq, but not a something
that should be added in application code. And the reason it is added is to
avoid joining queue thread from itself.

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