[gst-devel] dataflow synchronization

[Edgard Lima]

If you want something like:

videosrc ! tee tee0. ! queue ! videorendersink tee0. ! queue ! videoencsink

we could make

videosrc ! tee ! queue ! videorendersink tee0. ! queue ! videoreate !  
video/x-raw-yuv, framerate=\(fraction\)15/1   !  videoencsink

Or else

if your "videoencsink" has a rate property


BR,
Edgard Lima - alima
edgard.lima at indt.org.br



ext Benoit Fouet wrote:

>
>
> Wim Taymans wrote:
>
>>On Thu, 2006-04-27 at 18:39 +0200, Benoit Fouet wrote:
>>  
>>
>>>Hi,
>>>
>>>I've read Gstreamer documentation (i.e. Application Development Manual
>>>and Plugin Writer's Guide) and one point remains obscure to me.
>>>I can't figure out how data is synchronized over the pipeline.
>>>
>>>e.g. when having a pipeline as simple as an audio file source, a decoder
>>>and an audio plugin, the source is able to provide data much more
>>>quickly than the decoder can work, itself more quickly than the audio
>>>sink is able to flush data on driver.
>>>
>>>though, my question is: what is the event that allows an element to
>>>provide data over its source pad ?
>>>is it that gst_pad_push is called in the same thread, and is by the way
>>>blocking the upstream element, or are there other synchronization methods ?
>>>    
>>>
>>
>>Yep, pad_push() eventually blocks somewhere downstream, either in a sink
>>that does
>>synchronisation or another element that rate controls in one way or
>>another (queue, based on buffer size, some network element).
>>All elements in a pipeline share the same clock normally, a typical sink
>>waits for the clock to reach the propor time corresponding to the buffer
>>timestamps before rendering a buffer. As soon as the buffer is rendered
>>(or scheduled for rendering in the case of audio) pad_push() returns and
>>upstream elements can produce new data.
>>
>>Hope that explains,
>>Wim
>>
>>  
>>
> It does explain, thanks :)
> I have a related second question: in case an element has multiple 
> source pads (let's say 2 for instance), is there a way to have one of 
> them blocked and the other one allowed to produce new data ?
> e.g. if a video source element provides data to both a 
> renderer/display (rather quick) and an encoder (slower), is it 
> possible that the display element have access to more frames than the 
> encoder ?
> in other words, let's say you can produce 30 frames per second and you 
> encode at 15 but you want to display 30.
> do the downstream elements have to manage themselves to drop frames 
> they don't need ?
>
> Regards,
> Ben
>
>>  
>>
>>>Thanks,
>>>Ben
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>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-devel at lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>>    
>>>