[gstreamer-bugs] [Bug 475455] [bin] use internal_links for doing state changes

[GStreamer (bugzilla.gnome.org)]

http://bugzilla.gnome.org/show_bug.cgi?id=475455



--- Comment #14 from Sebastian Dröge <slomo at circular-chaos.org> 2009-08-22 13:25:31 UTC ---
(In reply to comment #10)
> Seems like the loop might have caused the problem. With pipelines like that we
> should really use the internal_links function to walk the graph (it is then
> does not really contain a loop).

How exactly would that work?

When walking the graph via pad connections (i.e. ... ---> sinkpad ---
internal_links ---> srcpad --- peer ---> sinkpad ) we would have a graph with
pads as nodes. For every pad it's possible to get the parent element of course.

Here it must be ensured that there is no cycle in the pads graph but there
could be cycles when transforming the pads graph to the corresponding elements
graph. Right?

For iterating over all elements in topological order we would then walk this
pad graph from the sink element's sink pads.



But when do we change the state of an element that owns a pad? The first time
when all "dependencies" for at least one srcpad are done? Example: a(src1,src2)
and (sink1)b, a.src1 is linked to b.sink1. After b has changed the state a can
change the state too, no matter what the peer element of a.src2 does.
Comparison: currently we require that all srcpad "dependencies" are done.
Does this work as expected? Probably not, because example:  a(src1,src2),
(sink1)b, (sink1)c. a.src1->b.sink1 and a.src2->c.sink1. a could then change
state already once b or c has changed the state. Which would in the end mean,
that a is trying to push data to an element in the wrong state (say a and b are
PAUSED, c is still READY).
If we allow to change state when at least one srcpad dependency is done but
require that for every bin state changes are done for those elements with the
least remaining srcpad dependencies, would this work? But isn't this then the
same behaviour as we have now?

If we require all srcpad dependencies to be done before changing the state
there should be no difference which graph is walked. Unless I'm missing
something the rtpbin<---->rtpbin loop example would then still not work because
both rtpbin would wait for the other.

-- 
Configure bugmail: http://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.