[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 #14 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-01-20 15:23:53 UTC ---
(In reply to comment #13)
> (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, that would mean it would be blocked forever in the sink for some reason
(like PAUSED forever or a deadlock). If it was the last buffer, at some point
gst_pad_push() will return... and then the IDLE probe will be called.

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

Yeah, can you get a backtrace for the joining thread from itself problem? It
indicates a conceptual problem elsewhere imo

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