[ntp:hackers] Fwd: Video Frame Rate Ref Clock

houston.jim at comcast.net houston.jim at comcast.net
Fri Dec 14 23:49:43 UTC 2012


> video signals. We will get time from NTP and use FR as freq source.
> 
> You might be asking why bother using FR as freq if you already have a good
> NTP source? b/c it may be the case that local vid FR is NOT GPS sync BUT
> must still be used in order to serve NTP to a remote video playout such
> that an end-to-end video distribution system (over IP) will NEVER drop/dup
> video frames. IOW, use the local PC locked to FR freq as NTP server for
> remote PC doing frame playout of the SAME video signal.

Hi Bart, Everyone,

In the case where the video FR is not GPS synchronized, you would
be having your own little island of timekeeping drifting out of
sync with the rest of the world.

How accurate does the synchronization between the local and remote
systems need to be?  Would the video source change with corresponding
changes in frequency?

I would be worried that the NTP on the remote system will not track 
frequency changes the way you might expect.  NTP can take hours to
compensate for a frequency error.  You can see the behavior by starting
NTP with an error introduced by changing the value in the frequency file.
If the local frequency changes, you will see the time error between 
the local and remote systems gradually increase and settle at a
peak proportional to the frequency error.  It has been a few years
since I worried about this, but I expect that a few ppm change in 
frequency will result in an synchronization error of several
milliseconds which lasts for hours.

Can you live with your systems having the incorrect time wrt to the
rest of the world?  If you have to occasionally fix the time you 
will probably confuse NTP.


Jim Houston



More information about the hackers mailing list