pipeline local data passing

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

pipeline local data passing

mattias-12
Hi, all.


What would be the best way to pass data/GST_BUFFERS between various
local machines that have separate parts of a complex pipeline?

I guess with NetworkTimeprovider/GDP/TDP the synchronisation would be
given for free and is a good alternative.
Also rtppay/udpsink -> udpsrc/rtpdpay/gstrtpjitterbuffer could also
maintain the timestamps between machines.

Could the TCP example have latency issues? We are talking about 10Gbit
low latency networks here.


Any input will be received gratefully,

Mattias

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: pipeline local data passing

Edward Hervey
Administrator
Hi,

On Tue, 2009-04-14 at 18:54 +0200, mattias wrote:

> Hi, all.
>
>
> What would be the best way to pass data/GST_BUFFERS between various
> local machines that have separate parts of a complex pipeline?
>
> I guess with NetworkTimeprovider/GDP/TDP the synchronisation would be
> given for free and is a good alternative.
> Also rtppay/udpsink -> udpsrc/rtpdpay/gstrtpjitterbuffer could also
> maintain the timestamps between machines.
>
> Could the TCP example have latency issues? We are talking about 10Gbit
> low latency networks here.

  There are two basic ways of splitting up pipelines accross machines:

  * Using GstNetTimeProvider on the master pipeline and
GstNetClientClock on the other pipelines to have the same clock rate,
and then the GDP payloading protocol over tcp for serializing buffers
and events. This is what's used by flumotion, and seems to scale pretty
well.
  * Using standard RTP/UDP.

  If you control the whole network and it's a local one, you might want
to consider the first option for several reasons:
  * tcp will not cause that much latency since you're controlling the
network.
  * gdp will allow *both* buffers and events to be serialized (as
opposed to rtp which only serializes buffers
  * you won't need a jitterbuffer since you will not have any packet
losses and you won't need to guess the remote clock rate (you're
distributing it with GstNetTimeProvider/GstNetClientClock. The
jitterbuffer *will* bring in some latency (which is needed for packet
drop detection and network jitter correction).

  You might want to have a look at flumotion for how this is being used.

    Edward

>
>
> Any input will be received gratefully,
>
> Mattias
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel