jltcntp - doesn't function with 29.97 drop-frame stream

[mungewell]

The drop-frame process means that the reported min/sec/frame values are not contiguous, this is not corrected for.

Write-up and fix in process.

[mungewell]

I don't believe (and probably should admit) how long this took with issues with interger math and overflowing.

It should be noted that you HAVE to specify correct frame rate on the CLI as this is used to calculate the times for the intermediate frames. Being pedantic it's also noteworthy that '2997/100' is not the same as '30000/1001'.

$ ./jltcntp -u 0 -f 2997/100 -v
00-00-00 +0000 00:59:59.21 (ahead 108 -> xx:59:59 & 699699us)
00-00-00 +0000 00:59:59.22 (ahead 108 -> xx:59:59 & 733066us)
00-00-00 +0000 00:59:59.23 (ahead 108 -> xx:59:59 & 766433us)
00-00-00 +0000 00:59:59.24 (ahead 108 -> xx:59:59 & 799799us)
00-00-00 +0000 00:59:59.25 (ahead 108 -> xx:59:59 & 833166us)
00-00-00 +0000 00:59:59.26 (ahead 108 -> xx:59:59 & 866533us)
00-00-00 +0000 00:59:59.27 (ahead 108 -> xx:59:59 & 899899us)
00-00-00 +0000 00:59:59.28 (ahead 108 -> xx:59:59 & 933266us)
00-00-00 +0000 00:59:59.29 (ahead 108 -> xx:59:59 & 966633us) <--- 33367us to next
00-00-00 +0000 01:00:00.00 (ahead 0 -> xx:00:00 & 0us) ==> Wed Jul 22 01:00:00 2020
00-00-00 +0000 01:00:00.01 (ahead 0 -> xx:00:00 & 33366us)
00-00-00 +0000 01:00:00.02 (ahead 0 -> xx:00:00 & 66733us)
00-00-00 +0000 01:00:00.03 (ahead 0 -> xx:00:00 & 100100us)
00-00-00 +0000 01:00:00.04 (ahead 0 -> xx:00:00 & 133466us)
00-00-00 +0000 01:00:00.05 (ahead 0 -> xx:00:00 & 166833us)
00-00-00 +0000 01:00:00.06 (ahead 0 -> xx:00:00 & 200200us)
00-00-00 +0000 01:00:00.07 (ahead 0 -> xx:00:00 & 233566us)
00-00-00 +0000 01:00:00.08 (ahead 0 -> xx:00:00 & 266933us)
00-00-00 +0000 01:00:00.09 (ahead 0 -> xx:00:00 & 300300us)

$ ./jltcntp -u 0 -f 30000/1001 -v
00-00-00 +0000 00:59:59.21 (ahead 108 -> xx:59:59 & 696100us)
00-00-00 +0000 00:59:59.22 (ahead 108 -> xx:59:59 & 729466us)
00-00-00 +0000 00:59:59.23 (ahead 108 -> xx:59:59 & 762833us)
00-00-00 +0000 00:59:59.24 (ahead 108 -> xx:59:59 & 796200us)
00-00-00 +0000 00:59:59.25 (ahead 108 -> xx:59:59 & 829566us)
00-00-00 +0000 00:59:59.26 (ahead 108 -> xx:59:59 & 862933us)
00-00-00 +0000 00:59:59.27 (ahead 108 -> xx:59:59 & 896300us)
00-00-00 +0000 00:59:59.28 (ahead 108 -> xx:59:59 & 929666us)
00-00-00 +0000 00:59:59.29 (ahead 108 -> xx:59:59 & 963033us) <--- 36967us to next!!
00-00-00 +0000 01:00:00.00 (ahead 0 -> xx:00:00 & 0us) ==> Wed Jul 22 01:00:00 2020
00-00-00 +0000 01:00:00.01 (ahead 0 -> xx:00:00 & 33366us)
00-00-00 +0000 01:00:00.02 (ahead 0 -> xx:00:00 & 66733us)
00-00-00 +0000 01:00:00.03 (ahead 0 -> xx:00:00 & 100100us)
00-00-00 +0000 01:00:00.04 (ahead 0 -> xx:00:00 & 133466us)
00-00-00 +0000 01:00:00.05 (ahead 0 -> xx:00:00 & 166833us)
00-00-00 +0000 01:00:00.06 (ahead 0 -> xx:00:00 & 200200us)
00-00-00 +0000 01:00:00.07 (ahead 0 -> xx:00:00 & 233566us)
00-00-00 +0000 01:00:00.08 (ahead 0 -> xx:00:00 & 266933us)
00-00-00 +0000 01:00:00.09 (ahead 0 -> xx:00:00 & 300300us)

[x42]

Being pedantic it's also noteworthy that '2997/100' is not the same as '30000/1001'.

The LTC spec (and SMPTE in general) specifies 3000/1001. That does however drift relative to wall-clock time. So many vendors use 2997/100 by convention since that comes out even over a period of 24 hours.

[mungewell]

Indeed.... https://videocide.com/glossary/drop-frame-timecode/ That is, drop-frame TC drops 18 of 18,000 frame numbers, equivalent to ​1⁄1000, achieving 30×0.999 = 29.97 frame/s. This is very slightly slower than the true NTSC frame rate of 30/1.001 = 29.97002997 frame/s, which is equivalent to dropping ​1⁄1001 frame numbers. The difference is one additional NTSC frame per 1,000,000 drop-frame TC values, which is negligible.

[mungewell]

In case it's useful for anyone... 20200732_chrony_2997fps.tar.gz

[x42]

since #21 was merged as 57ee29dfc999c, can this be closed?

[mungewell]

Yes I believe so. Thanks.