[gst-devel] Circular pipes.

[Benjamin Otte]

On Tue, 30 Mar 2004, Andy Wingo wrote:

> It turns out I didn't even get to check which pad aggregator would
> choose to pull from first (should be the first connected pad, imo).
>
Every element is free to pull on any pad it sees fit. Relying on the order
in which data is pulled or pushed by elements is broken and may lead to
deadlocks in a further version of GStreamer. If you must rely on it, use
the workaround to add (a thread and) queues in between.

> The question now is, whose fault is the error? Is it the fault of the
> aggregator getcaps function (incidentally set to proxy_getcaps), for not
> noticing the the element was already in negotiation? Is it the fault of
> gstpad.c, for similar reasons? Or is it the fault of the pipeline author
> for not noticing that there is a cycle, and putting in a magical element
> that will break getcaps (and query, and event, and ...) loops?
>
I think the current support for cyclic pipelines goes something like this:
It should work, but noone did the work so it most likely doesn't.
Since we all didn't think about it very much, it's likely that it won't
ever be possible with elements that allow cycles.

The problem is that if the core were to support cyclic pipelines, a
pipeline like a filter connected to itself with a buffer magically
inserted like in your example would have to work. I'm pretty sure that's
very hard to do without support from the element.


Benjamin