From: Wim T. <wi...@fl...> - 2006-04-27 16:53:26
|
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 > > 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 > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel -- Wim Taymans <wi...@fl...> |