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 |
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 |
Free forum by Nabble | Edit this page |