[gst-devel] dataflow synchronization
edgard.lima at indt.org.br
Fri Apr 28 09:11:03 CEST 2006
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
if your "videoencsink" has a rate property
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:
>>>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
>>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,
> 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 ?
>>>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
>>>gstreamer-devel mailing list
>>>gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel