[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 #10 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-01-20 14:32:51 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > The problem of not using IDLE probes is that you might never release a pad then
> > if there's no further data flow. That's not very expected from the application
> > I guess.
> 
> Using IDLE probe does not guarantee against callback being never executed, too.
> That's why i proposed guaranteed-synchronous probe type. Maybe that's not that
> bad idea to have it?

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.


> > This dropping of upstream data resulting in shutdown from the streaming thread
> > seems like an indication that something is not yet as it should be ;) Do you
> > have a backtrace of this?
> 
> You must be talking about
>  +  if (info->type & (GST_PAD_PROBE_TYPE_DATA_UPSTREAM
>  +          | GST_PAD_PROBE_TYPE_QUERY_UPSTREAM))
> 
> No, i haven't saved a backtrace and haven't got a testcase for it. I remember
> it to happen surely only once. I don't remember what exactly the query was, and
> what was the pipeline. Maybe you could make a case to trigger this scenario,
> with your knowledge.

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.

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