GNOME Bugzilla – Bug 627796
rtpbin: add ntp clock sync
Last modified: 2010-09-06 09:24:45 UTC
This feature enables synchronized playback between multiple receivers. To enable this feature set the ntp-sync property on gstrtpbin on *and* sync the clocks on the rtp sender/receiver. This ensures that the buffers get the same NTP timestamp on all systems. changes: - set ts-offset on gstrtpjitterbuffer - use the clocktime in the sender for the rtcp sr packets - set buffer-mode of gstrtpbin to none (RTP timestamps)
Created attachment 168612 [details] [review] rtpbin: add ntp clock sync
This patch can be improved. I would like to see it work without changing the buffer-mode or changing the NTP clock. The current receiver calculates a diff between streams to keep them synchronized. What really should happen is that each stream individually is adjusted so that the right RTP timestamps are played at the right NTP time. If receivers then have their NTP times synchronized, streams will be in sync. For this, a mapping should be made between running_time and NTP time. We can already map RTP timestamps to running_time by using the jitterbuffer values. We can also map RTP time to NTP time with SR packets. It's then not so hard to calculate a diff to adjust the running_times. No buffer-time should be changed for this to work. No shared pipeline clock is needed either. The only thing needed is a shared NTP time. As an addition, when you don't want to sync clients using ntpd, you can add a property to gstrtpbin to set the clock used for generating NTP timestamps. Maybe the only two interesting options for generating NTP times are either to use the (gstreamer synchronized) pipeline clock or the (ntpd synchronized) system-time..
Review of attachment 168612 [details] [review]: ::: gst/rtpmanager/gstrtpsession.c @@ +767,3 @@ + if (rtpsession->ntp_sync) { + ntpns = gst_clock_get_time (clock); If I understand, all you are doing is using the pipeline clock for the NTP time instead of a system clock ? So shouldn't the property be called "use-pipeline-clock".. And why is it not the default ? Is it because the pipeline clock can be changed?
> "use-pipeline-clock".. And why is it not the default ? Is it because the > pipeline clock can be changed? You would always prefer to use the system clock for making NTP times so that multiple machines can sync their NTP times with ntpd. I guess this is just a convenient default (and allows interop with other devices out of the box). You could easily use a synchronized GStreamer clock as well (which is the option I talk about in Comment 2).
Like discused on IRC, there can be both a usecase for a ntpd synchronized clock and a GStreamer synchronized clock. Will check to add the property to gstrtpbin, maybe like the proposed "use-pipeline-clock"... (it's indeed only doing that in rtpsession) (In reply to comment #2) > This patch can be improved. I would like to see it work without changing the > buffer-mode or changing the NTP clock. The problem is that the network delay is taken into account for defining the timestamp of the buffer. And as this can be different on multiple machines synchronization is not guarenteed. Any pointer to howto disable this network delay in the TS calculation?
(In reply to comment #5) > Like discused on IRC, there can be both a usecase for a ntpd synchronized clock > and a GStreamer synchronized clock. Will check to add the property to > gstrtpbin, maybe like the proposed "use-pipeline-clock"... > (it's indeed only doing that in rtpsession) Yeah, no problem for making a property to use the pipeline-clock for sync (or even a clock property to set any clock, dunno if that would make sense). > > (In reply to comment #2) > > This patch can be improved. I would like to see it work without changing the > > buffer-mode or changing the NTP clock. > > The problem is that the network delay is taken into account for defining the > timestamp of the buffer. And as this can be different on multiple machines > synchronization is not guarenteed. Any pointer to howto disable this network > delay in the TS calculation? Yes, I realized this too after thinking about it a bit... The problem is not so much the network delay because if you have a shared NTP time, you can on each machine play the RTP packet that goes with the NTP time and have them synced. The problem is that when you receive a packet, its presentation NTP time (assuming you are synched with the receiver, but if you aren't it can be even worse) already passed because of the network delay (the NTP time for an RTP packet is when it was sent on the server). So you would have to distribute some sort of delay to all receivers, which could be done (like maybe the latency could be used in some way, which could maybe also conveniently avoid us to set the same latency on all receiver pipelines). Need to think some more..
Created attachment 168787 [details] [review] rtpbin: add use-pipeline-clock property With this property RTCP SR NTP times can be based on the system clock (maybe synced with ntpd) or the current pipeline clock.
splitting the patch in 2 parts as they can be applied unrelated. (In reply to comment #6) > Yes, I realized this too after thinking about it a bit... The problem is not so > much the network delay because if you have a shared NTP time, you can on each > machine play the RTP packet that goes with the NTP time and have them synced. That is what is happening in the first patch. (or at least what I'm trying too) All packets should have the same rtp to ntp (buffer timestamp) convertion, with the ts-offset. > The problem is that when you receive a packet, its presentation NTP time > (assuming you are synched with the receiver, but if you aren't it can be even > worse) already passed because of the network delay (the NTP time for an RTP > packet is when it was sent on the server). So you would have to distribute some > sort of delay to all receivers, which could be done (like maybe the latency > could be used in some way, which could maybe also conveniently avoid us to set > the same latency on all receiver pipelines). Need to think some more.. Indeed, therefore in my setup I set the latency fixed on the receivers. Didn't find a place in RTP/RTCP where we can put this latency...(can we make an extension for this?)
(In reply to comment #8) > splitting the patch in 2 parts as they can be applied unrelated. OK, will push this patch after release.
Created attachment 168817 [details] [review] rtpbin: add use-pipeline-clock property With this property RTCP SR NTP times can be based on the system clock (maybe synced with ntpd) or the current pipeline clock.
Created attachment 168818 [details] [review] rtpbin: add ntp clock sync This feature enables synchronized playback between multiple receivers. To enable this feature set the ntp-sync property on gstrtpbin on *and* sync the clocks on the rtp sender/receiver. This ensures that the buffers get the same NTP timestamp on all systems.
I will push an improved patch that also works with synchronized ntp times.
commit 93228ccd525f318fa1ad633ed28c5a728b5740ef Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Aug 27 17:58:47 2010 +0200 rtpbin: add ntp-sync property Add an ntp-sync property that will sync the received streams to the server NTP time. This requires synchronized NTP times between the sender and receivers, like with ntpd. Based on patch from Thijs Vermeir. Fixes #627796