<div dir="ltr">Hi Sebastian.<br><div><div class="gmail_extra"><br></div><div class="gmail_extra">Please see comments in-line.<br><br></div><div class="gmail_extra">Sorry for being difficult. I'm probably missing an important point here.<br><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 23, 2015 at 12:27 PM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Di, 2015-06-23 at 12:17 +0200, Peter Maersk-Moller wrote:<br>
> Hi Sebastian.<br>
> Thanks for the answer/example. So what I read from the example is<br>
> that nothing needs to be changed for the sender (liver source):<br>
</span>No, you need to use "use-pipeline-clock" at least. And ensure that both<br>
pipelines (sender and receiver) are using the same clock. You can't do<br>
that with gst-launch!<br></blockquote><div><br></div><div>I probably misunderstand. Are you telling me to use pipeline-clock in the sender?<br></div><div>Isn't the pipeline-clock a clock that starts at 0 when the pipeline starts?<br><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Assuming each source of RTP/RTCP streams are in agreement about time<br>
> using ntpd to set/adjust the clock locally, should this pipeline play<br>
> the content synchronized not only with audio/video synchronized but<br>
> also synchronized for other similar pipelines?<br>
</span>No, the important part here is that via RTCP some clock time exchange<br>
will happen and then the timestamps on the receiver side are exactly<br>
the same clock time as on the sender side.<br></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Related your later questions: codec and stuff does not matter, what<br>
matters are the timestamps (the buffer timestamps in clock time must be<br>
the same in the end! PTS or running time don't matter), the same clock<br>
and that all receivers use the same latency.<br></blockquote><div><br></div><div>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 ?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> A couple of things though:<br>
> ntp-time-source does not seem to be a settable parameter for rtpbin<br>
> for (Currently using GStreamer 1.4.5) when listing the module with<br>
> gst-inspect-1.0. So how do I set it through CLI using gst-launch-1.0?<br>
</span>You need 1.5.1 or GIT master. And you can't use gst-launch for all of<br>
this, see above. Please write some proper code instead of using gst<br>
-launch, gst-launch is only a testing tool.<br></blockquote><div><br></div><div>So you keep telling me :-) I think gst-launch is a very useful application :-)))) for which I can only thank for too little.<br><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You will most likely also need the new gst_pipeline_set_latency() API<br>
on the receivers.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div class="h5">Thanks for patience and help so far.<br><br>Regards<br>Peter MM<br></div></div></div></div></div>