List Info

Thread: Why exactly we need "queue" element while connecting multiple srcpads ?
Why exactly we need "queue" element while connecting multiple srcpads ?
user name
 2007-02-06 07:12:10 

  


  

    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 ? 


When I know the expected data flow & behaviour of all elements I'm connecting here, I would like to remove this overhead in between.

Thanks, 
--vinayak



  

  
  
   
     
    

  

    Re:  Why exactly we need
"queue" element
while	connecting multiple srcpads ?
  


  

     country flaguser name
Finland		
     2007-02-07 02:22:42
  


  

    
hi,

Quoting Vinayak <vinayak.panegmail.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.

> When I know the expected data flow & behaviour of
all elements I'm
> connecting here, I would like to remove this overhead
in between.

The overhead should be relative minimal. The queue will
forward the  
buffers as soon as it has some and it gets scheduled.
>
> Thanks,
> --vinayak

Stefan


------------------------------------------------------------
-------------
Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to
make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
gstreamer-devel mailing list
gstreamer-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstream
er-devel



  


  

    
  

  
  
   
     
    

  

     Fwd: Why exactly we need
"queue" element while
connecting multiple srcpads ?
  


  

     user name

     2007-02-07 03:32:35
  


  

    

  


  

    

---------- Forwarded message ----------
From: Vinayak < vinayak.panegmail.com">vinayak.panegmail.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 < ensonichora-obscura.de">ensonichora-obscura.de>


hi,

On 2/7/07, Stefan Kost < ensonichora-obscura.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ensonichora-obscura.de> wrote:

hi,

Quoting Vinayak < vinayak.panegmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">vinayak.panegmail.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.
&gt; 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,&nbsp; 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



  

  
  
   
     
    

  

    Re:  Fwd: Why exactly we need
"queue" element
while	connecting multiple srcpads ?
  


  

     country flaguser name
United Kingdom		
     2007-02-07 04:34:53
  


  

    
On Wed, 2007-02-07 at 15:02 +0530, Vinayak wrote:

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

The problem here is that the sinks will block when they are
prerolled
(ie. have obtained a first buffer usually). So your first
sink gets its
first buffer, changes to PAUSED state and blocks. Now the
tee/demuxer is
stuck in gst_pad_push() and never gets to push a buffer to
the second
sink, so the second sink will never preroll and the pipeline
can't
change from READY into PAUSED state. Adding a queue works
around this
because it's only the queue's new streaming thread that is
blocked by
the sink, so the tee/demuxer can continue to push further
buffers to the
other sinks.

 Cheers
  -Tim




------------------------------------------------------------
-------------
Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to
make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
gstreamer-devel mailing list
gstreamer-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstream
er-devel



  


  

    
  

  
  
   
     
    






 [1-4]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )