Synchronizing multi-cast receivers?

[Spruyt, Randy]

Thank you kindly for the response Sebastian, I'll give this a try.

-----Original Message-----
From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Sebastian Dröge
Sent: Wednesday, June 10, 2015 11:17 AM
To: Discussion of the development of and with GStreamer
Subject: Re: Synchronizing multi-cast receivers?

On Mi, 2015-06-10 at 17:13 +0200, Sebastian Dröge wrote:
> On Mi, 2015-06-10 at 14:09 +0000, Spruyt, Randy wrote:
> > A general question,
> > 
> >  
> > 
> > With 1 multicast server and 2 receivers, both receivers using an NTP
> > clock. The playback starts off synchronized, but drifts apart over
> > time. The current theory is the rtpjitterbuffer is adjusting the PTS
> > to account for volatility in the network. How would one ensure both
> > playback receivers play the stream at exactly the same time (to the
> > frame)? If a frame needs to be dropped that is fine, but the
> > presentation time must remain the same on both.  
> 
> The easiest would be the following, assuming you have live streams.
> - set use-pipeline-clock=TRUE on all rtpbins
> - set buffer-mode=sync, ntp-sync=TRUE on the receiver rtpbins
> - set the *same* clock on all pipelines, i.e. a GStreamer
>   netclientclock, NTP or PTP clock. Or make sure that your system
>   clocks are synchronized externally, and that the system clock
>   you set on the pipelines has clock-type=realtime (not monotonic!).
> - set start_time=GST_CLOCK_TIME_NONE and base_time=0 on all pipelines
> - NOTE: You must ensure that RTCP is working!
> 
> Now the receivers will get exactly the same PTS (except for rounding
> errors) as the sender, and will sync them to the same clock. The only
> possible difference is now the latency introduced by decoders and other
> things on the receivers after the RTP depayloading. To get around that,
> you could configure manually a latency on all receivers that is the
> maximum of all receiver latencies.
> 
> 
> If you want to stream non-live pipelines like this, you would have to
> either make sure that the running time on the sender is offset by the
> current clock time at the beginning, or you don't set the
> base_time/start_time on the sender and have to set exactly the same
> base_time on all receivers that was selected by the sender. You somehow
> have to pass this information out of band from the sender to the
> receivers.

Oh I forgot, you can find an example of this using gst-rtsp-server and
the GStreamer netclock here. It only works for live pipelines.

http://cgit.freedesktop.org/gstreamer/gst-rtsp-server/tree/examples/test-netclock.c
http://cgit.freedesktop.org/gstreamer/gst-rtsp-server/tree/examples/test-netclock-client.c

How to change that to a different clock should be trivial, just use a
different one. Making this work for non-live pipelines needs some more
changes as explained above.


If you don't want to use RTSP but plain RTP, it all works exactly the
same. That example only uses RTSP to make the rtpbin setup a bit
simpler.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com