[gst-devel] Fwd: Why exactly we need "queue" element while connecting multiple srcpads ?

[Vinayak]

---------- Forwarded message ----------
From: Vinayak <vinayak.pane at gmail.com>
Date: Feb 7, 2007 2:39 PM
Subject: Re: [gst-devel] Why exactly we need "queue" element while
connecting multiple srcpads ?
To: Stefan Kost <ensonic at hora-obscura.de>

hi,

On 2/7/07, Stefan Kost <ensonic at hora-obscura.de> wrote:
>
> hi,
>
> Quoting Vinayak <vinayak.pane at gmail.com>:
>
> > Hi,
> > My query is, Why do we need a "queue" element in between when we want to
> > push data to multiple srcpads ?
> > Without connecting this element I just cant push my data to next peer
> > plugin.
> > Is there any workaround to avoid using queue ?
> No. The queue is not only buffering, it provides a thread boundary and
> thus decouples the 1:n element from each uf the downstream chains. If
> you don't use the queues, one slow sink could starve the whole
> processing.


True, queue creates thread boundary.
But how do I implement 1:n demuxer without using "queue".
With reference to design document,  I could figure out what pads can be
connected.
Push mode src pad should work with both loop and chain based. But when I
push something to such srcpad nothing gets pushed and the function just
hangs up. Is it waiting for some event/criteria which "queue" element only
can satisfy?

When does the gst-engine query to pad about the scheduling policy ?


Thanks,
./v
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20070207/164a2e97/attachment.htm>