Synchronizing multi-cast receivers?
sebastian at centricular.com
Wed Jun 10 08:13:57 PDT 2015
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
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 949 bytes
Desc: This is a digitally signed message part
More information about the gstreamer-devel