Using NTP TimeStamps

OccuRec can use internet time provided by NTP servers to timestamp your video. If you have a GPS-based video time inserter (e.g. IOTA-VTI) then it should be your choice for timing. However if you don't have a GPS time source you can use NTP timing to timestamp your video with an absolute accuracy of 100ms or less. OccuRec has been extensively tested on a number of systems with modern PC hardware that have fast ASDL internet and has demonstrated to be able to timestamp millions of consecutive video frames with a great accuracy (consistency of 10ms). The only remaining external factors for the actual accuracy that you can achieve are (1) your choice of NTP servers and (2) the calibration correction for your system and frame grabber.

Before you decide to be using NTP-based timestamps you need to be sure that you have a modern PC hardware (ideally no more than a couple of years old) and that you have a fast ADSL internet connection (at least a couple of megabits download speed and a megabit or so upload speed). You can use online internet speed tests to determine what your internet speed is.

Your next step will be to go to the Settings -> "Astro Analogue Video (AAV)" -> "NTP Timestamps", enable the NTP timestamps and configure your 4 different NTP servers. You should try to use whenever possible only Stratum 1 and Stratum 2 servers. Bare in mind that even that Stratum 1 servers are slightly more accurate, a Stratum 2 server that is 20ms away from you is much better than a Stratum 1 server that is 100ms away from you. Please note that not all public servers are always online. Do not use the default NTP servers (which are in Australia) unless you are in the Australia/New Zealand region. Those servers will be very slow for you if you are in Europe, Asia or America.

Once you have configured your servers and every time before you intend to record NTP timestamped video, you should test the servers response times pressing the "Test Servers" button on the form above. This should give you a good indication of what timing consistency to expect. The two screenshots below show the average latency that I am getting from the default servers when testing from Sydney, Australia. The first image is testing through my G3 mobile internet connection and the second image is testing via the dedicated DSL link in the office. There is a 10 times difference in the latency as expected.


The last parameter in the equation is the Calibration Correction. This was something discovered experimentally during the accuracy testing. Basically every video frame will arrive in Windows with some delay and because of this the time at which it will be timestamped will be after the frame was exposed i.e. will be late. The Calibration Correction is a correction that fixes this delay. While I was hoping to come up with a practical test that people can perform to determine their Calibration Correction without the need of GPS time, I wasn't able to think of such a test. So please ignore the notice on the settings form that you should check the documentation to learn how to measure it experimentally. At this point it can be only measured if you can timestamp with both NTP time and GPS time - which defeats the purpose of using NTP time.

My current take on the Calibration Correction is that it should depend on the frame grabber being used and may be even on the video camera. I also believe that the delay should be typically a whole number of video field durations as I believe it may be related to the buffering of the images in the frame grabber or in the camera or both. I know that the Calibration Correction for an EasyCAP frame grabber and a PAL video turned out to be 60ms or 3 PAL video fields (1 and a half PAL video frame). I would suggest to leave the Calibration Correction unchanged in your case and to quote a timing accuracy of 100 ms. If NTP time is your only timing reference for video observation, even with 100 ms accuracy your observations will be very valuable and quite possibly 100ms is a very conservative error estimate (i.e. your accuracy will be likely better).

The graph below shows the result of a 48 hour continuous run of NTP timestamping using OccuRec. In this case OccuRec was running in a special mode where it has not been recording video but has been only recording three sets of timestamps. The timestamp based on NTP time using the internally kept time (based on CPU clock and using QueryPerformanceCounters API), the timestamp using the Windows clock (synchronised to NTP every minute) and the timestamp OCR-ed on the fly from an IOTA-VTI inserted timestamp (with a precision of 0.1 ms). The plot shows the difference for each video frame (at 25fps) between the IOTA-VTI timestamp and OccuRec's NTP timestamp (in green) and the IOTA-VTI timestamp and the Windows Clock based timestamp.

As you can see the Windows Clock timestamp is scattered around in the 200ms error interval and has been always late. The OccuRec's NTP timestamp is very well on target with an error of ~10ms. This recording has been done with a Calibration Correction of 60ms and the frame grabber was EasyCAP. It is also interesting to note that there are numerous and consistent green ticks that are 40ms off. They correspond to an internal problem with the frame grabber which was consistently incorrectly combining 2 video fields every ~24 minutes. It is possible that other frame grabbing hardware has similar problems but because there is only 1 wrongly combined video frame for 25 min this is something hard to catch. The most likely explanation for this particular error once every 24 minutes could be an overflow of an internal integer counter.

Gerhard Dangl has described a similar issue with another video grabbing hardware and he has documented it as The problem of combining wrong fields to frames. While this is not something hugely problematic, neither it is really related to the NTP timestamps in OccuRec, I thought it would be curious to mention as it was discovered by the long running NTP timestamping accuracy tests.

It is important to note that OccuRec has a way of dealing with the problem of wrong fields being combined (where the odd and even fields have changed their position). It always records one unmodified video frame in an AAV file - this is the first video frame. Manual examination of the order of the VTI-OSD timestamps will reveal if they are wrongly combined. The automatic OCR-ing of the IOTA-VTI timestamp will also alert the user if the wrong fields are combined. However I haven't seen the wrong field combination problem with my equipment. If you have wrongly combined fields with your NTP timestamped video then there is no way you can tell. The end result for you will be that your time estimates will be 20 ms off, which falls well into the 100 ms error that I suggest to be used with NTP derived times.

Reading NTP TimeStamps with Tangra

Tangra 3.1.18 or later will automatically read the NTP timestamps saved with AAV files and will use them as a time reference.

It is also worth noting that OccuRec calculates and records in the AAV file both the NTP-based timestamp for the begining and the end of the frame:

However the NTP timestamp displayed on the AAV Frame Channel is the end frame timestamp. Further to this when instrumental delays have been applied, the tool tip over the green asterisk will give the timestamp for the end of the first field, while the timestamp associated with the frame will be the middle of the exposure (NTP-based). All this is consistent with how Tangra works with the other cases: embedded timestamp, OCR-ed timestamp or user entered timestamp.