Re: [gst-devel] dataflow synchronization

[Benoit F. <ben...@pu...>]

Thank you !

I don't really think I would need a queue before the video renderer,
unless it is mandatory, so that I can have as less threads as possible
to avoid context switch as much as I can.
I wonder one thing (again :-) ): tee elements can have two different
frame rates on their source pads ? i guess so, but it's to be sure...

Thanks again,
Ben


Edgard Lima wrote:

>
>
> 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
> edg...@in...
>
>
>
> 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
>>>> gst...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>>>   
>>>
>
>
>
> -------------------------------------------------------
> 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