Synchronizing multiple RTP sources

[Peter Maersk-Moller]

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.


> > 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.


> 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 ?

>
> > 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.


>
> You will most likely also need the new gst_pipeline_set_latency() API
> on the receivers.
>

Got it. Have to go to 1.5.1 or GIT master. Will update and start
experimenting with some code. Synchronized source playout will make life
easier for me in the Snowmix Video Mixer I develop. Mixing is a lot harder
when things are not perfectly in sync.

Thanks for patience and help so far.

Regards
Peter MM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150623/de0c6474/attachment.html>