[gstreamer-bugs] [Bug 627796] rtpbin: add ntp clock sync

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Aug 25 12:39:47 PDT 2010


https://bugzilla.gnome.org/show_bug.cgi?id=627796
  GStreamer | gst-plugins-good | unspecified

--- Comment #6 from Wim Taymans <wim.taymans at gmail.com> 2010-08-25 19:39:40 UTC ---
(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..

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list