[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 #11 from Andrey Utkin <me at andrey-utkin.pp.ua> 2014-01-20 14:50:07 UTC ---
(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.

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

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