Re: [gst-devel] multiple chain vs one loop

[Ronald B. <rb...@ro...>]

Hi Daniel,

On Tue, 30 Mar 2004, daniel fischer wrote:
> 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. ?

It's not the right solution. Use select to probe for input on the image
sink, and keep pulling from the other. As Martin pointed out, selecting is
broken, but I'll come back to multi-chain below.

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

Definately not. The scheduler has no notion of timestamps, so even if this
would be possible, you'd get out of sync very fast. Because nobody defines
that the two input threads will read at the same speed (and what speed?
frames? bytes? seconds)... Not a good idea. If you need synchronized
inputs, make your element do that. We might want to add some helper stuff
in the core for this, but the scheduler will not solve this for you.

For multi-input elements, use a loop-function... :).

Ronald