Synchronizing multiple RTP sources

[Peter Maersk-Moller]

Hi Sebastian.

Thanks for hints and tips. Will try both your rtsp example and a manual
with just RTCP and rtpsession/rtpbin with the suggested parameters for
version 1.5.2. Goal is sync and minimal delay. Perhaps both solutions will
provide same delay.

Best regards
Peter MM

On Tue, Jun 23, 2015 at 7:33 PM, Sebastian Dröge <sebastian at centricular.com>
wrote:

> On Di, 2015-06-23 at 19:18 +0200, Peter Maersk-Moller wrote:
> > Hi Sebastian.
> >
> > Please see comments in-line.
> >
> > Sorry for being difficult. I'm probably missing an important point
> > here.
> >
> > On Tue, Jun 23, 2015 at 12:27 PM, Sebastian Dröge <
> > sebastian at centricular.com> wrote:
> > > On Di, 2015-06-23 at 12:17 +0200, Peter Maersk-Moller wrote:
> > > > Hi Sebastian.
> > > > Thanks for the answer/example. So what I read from the example is
> > > > that nothing needs to be changed for the sender (liver source):
> > > No, you need to use "use-pipeline-clock" at least. And ensure that
> > > both
> > > pipelines (sender and receiver) are using the same clock. You can't
> > > do
> > > that with gst-launch!
> > I probably misunderstand. Are you telling me to use pipeline-clock in
> > the sender?
> > Isn't the pipeline-clock a clock that starts at 0 when the pipeline
> > starts?
> >
> > Will that work when we have two independent senders, each on their
> > own system and we eventually want to play-out the two sender streams
> > synchronized but each stream in its own playout process? I'm probaly
> > missing the point here.
>
> That's why you need to ensure to use the same clock on sender and
> receiver. Both should report the same times.
>
> This could be done with the GStreamer network clock, a GStreamer PTP or
> NTP clock. Or by using the GStreamer system clock (make sure to set it
> to wall clock time) and outside GStreamer ensuring that the system
> clocks are synchronized.
>
>
> Alternatively you can also not use ntp-clock-source=3 on sender *and*
> receiver (and leave it at 0), in which case you only need to ensure
> that the wall time clock on senders and receivers are reporting the
> same time. This can be less accurate though.
> I didn't really test the case where the pipeline clocks on sender and
> receiver are different, as it's much easier to ensure synchronization
> of the clock inside GStreamer than making sure the system time is
> properly synchronized. See the example applications I linked.
>
>
> (Don't use use-pipeline-clock anymore, it's deprecated in favour of ntp
> -clock-source)
>
> >  > Assuming each source of RTP/RTCP streams are in agreement about
> > time
> > > > using ntpd to set/adjust the clock locally, should this pipeline
> > > play
> > > > the content synchronized not only with audio/video synchronized
> > > but
> > > > also synchronized for other similar pipelines?
> > > No, the important part here is that via RTCP some clock time
> > > exchange
> > > will happen and then the timestamps on the receiver side are
> > > exactly
> > > the same clock time as on the sender side.
> > Ok. But still confused. The two senders may have the same
> > understanding about time through ntp synchonized system time, but
> > they will usually have started at different times. But since they
> > have same system time, the timestamps together with each streams RTCP
> > sender report will provide each separate rtpbin in the playout end
> > with information about how timestamps relates to absolutely system
> > time and as a consequence of ntp, also the wall clock.
>
> The GStreamer clocks would report the same times on sender and receiver
> if you make sure to use the same clock in both pipelines. What is
> different is the base time and thus the running time.
>
> The use of ntp-sync=true and buffer-mode=synced and ntp-sync-source=3
> would make sure that the different base times are calculated away again
> based on the NTP times from the RTCP SR.
>
> > >  Related your later questions: codec and stuff does not matter,
> > > what
> > > matters are the timestamps (the buffer timestamps in clock time
> > > must be
> > > the same in the end! PTS or running time don't matter), the same
> > > clock
> > > and that all receivers use the same latency.
> > Got it. So two end-to-end-systems  (producer and playout) will
> > playout in sync, if system time on each producer is the same, because
> > the two systems end-to-end will have the same delay. At least that is
> > what I think you are writing. I assume that only work if one of them
> > does not have considerably longer network delay compared to the other
> > ?
>
> Yes, see also my remark about gst_pipeline_set_latency(). You would
> there have to configure the biggest latency of all receivers (including
> network and decoder latency!).
>
> >> A couple of things though:
> > > > ntp-time-source does not seem to be a settable parameter for
> > > rtpbin
> > > > for (Currently using GStreamer 1.4.5) when listing the module
> > > with
> > > > gst-inspect-1.0. So how do I set it through CLI using gst-launch
> > > -1.0?
> > > You need 1.5.1 or GIT master. And you can't use gst-launch for all
> > > of
> > > this, see above. Please write some proper code instead of using gst
> > > -launch, gst-launch is only a testing tool.
> > So you keep telling me :-) I think gst-launch is a very useful
> > application :-)))) for which I can only thank for too little.
> >
> > Okay, tried to avoid it for years after looking at the documentation,
> > but there seems no other way around it. It's a little bit odd that
> > somebody has not already written a CLI GStreamer based app, that can
> > playout (to your choice of sink) through mutiple independent
> > pipelines synchronously.
>
> I linked you to one in my previous mail :) That does exactly what we're
> talking about here all the time, and uses RTSP to exchange the stream
> parameters.
>
>
> --
> Sebastian Dröge, Centricular Ltd · http://www.centricular.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150625/254a5a46/attachment-0001.html>