[gst-devel] multiple chain vs one loop

[Martin Soto]

Hello Daniel,

On Tue, 2004-03-30 at 22:47, daniel fischer wrote:
> the (interesting) discussion about schedulers made me think about
> something else: iirc i read something in the docs that "you shouldnt
> do multiple chain functions at all. do a loop." this seems to be
> not(/no longer?) the case?

Well, yeah. I suppose the behavior in that case was not defined, so
you're actually on your own if you do that. Your millage may vary
depending on the scheduler you pick.

> a situation where multiple chains would win over a loop imo could be
> an "overlay" node that paints a small picture on a larger video stream
> (like a logo inserter). the imagesrc or whatever could just push a
> buffer whenever it's "location" property changes, and the overlay
> would keep (and use) the old buffer as long as it's logo_sink doesnt
> chain() again. ?

The situations you describe are all appropriate for the select
operation, namely, you wait on many pads until one of them has
information available. GstElement has a complete api for that, the only
problem is that no existing scheduler implements the underlying select
operation properly, so it never really works :-P

As you may have seen, our current attempt at defining the behavior of an
element with many chain functions is that such functions exclude each
other in such a way that they are guaranteed to never run concurrently.
In practice, that would be like performing a select operation on the
affected pads, and then running the corresponding chain function until
it finishes. The actual result is that if we manage to implement this
properly, you will be able to choose between using a loop with a select
operation or using many chain functions, and that will always result in
a predictable behavior. So, if everything goes well, the right
alternative will soon be just a matter of taste.

> a different but similar situation would be some video mixing element
> receiving buffers at multiple inputs (obviously :), at different
> framerates. one could think that this could be handled much better
> with multiple chain functions than with just a loop that pull()s
> exactly one buffer for each element. but then again, if it does regard
> the timestamps properly and does some sync magic, a loop might be
> appropriate.

If you are sure that material will be available from all sources, a
normal loop function that reads a fixed number of frames from each pad
in every iteration will do. If, on the other hand, you must depend on
the timestamps to do the job (i. e. you can have interruptions in the
input streams) the select solution would be your only option.

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>
Universität Kaiserslautern