[gst-devel] Circular pipes.

[Andy Wingo]

Yo,

I tried to set up a circular pipeline last night, to see what opt would
do with it. It looked like this:

  +-------------+   +----------+    +----+    +------------+
  |fakesrc      |-->|          |--->|tee +--->|fakesink    |
  |num-buffers=1|   |aggregator|    |    |-\  |            |
  +-------------+ ->|          |    +----+ |  +------------+
                  | +----------+           |
                  |                        |
                  | +------------+         |
                  \-|identity    |         |
                    |loop-based=1+<--------/
                    +------------+

(I would like to thank / blame artist-mode for that drawing.)
(Also parenthetically, opt choked when identity was a chain. It's
logically another group in either case, but opt didn't detect that.)

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). It
got stuck in an infinite getcaps loop, something that's not
scheduler-specific at all. Anyone familiar with the caps system can see
how that could come about.

Now, it is my opinion #1 that gst should support cycles in pipeline
topologies. I number the opinion in hopes that replies will be clear ;)
Synthesis applications often use this kind of structure.

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'm inclined to believe that the element is not at fault. It shouldn't
have to store negotiation-local state. So it would be either the fault
of GST core, or the app. These loops will happen for any function that
_dispatches_ to all pads but one. And I say dispatch, because that's how
most query, event, format, etc. functions are implemented.

Perhaps the app should be required to notice cycles and insert a
cycle-breaking element (perhaps called "cycle-breaker") that would guard
against all cyclical core actions. That shares the blame between the
core and the app. The core, because cycle-breaker has to be kept
up-to-date with all dispatch functions; and the app, because the app
needs to actually notice the cycle and insert the proper element.

Thoughts on the assignment of blame, and the proposal for the solution?
-- 
Andy Wingo <wingo at pobox.com>