[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AVT] Re: Carrying SMPTE time-codes in RTP streams, discussion email

At 4:35 PM -0800 2/13/05, lazzaro wrote:
On Feb 13, 2005, at 4:06 PM, Dave Singer wrote:
here is the draft. 

Looks good, I never realized:

   It is worth noting that in neither case is the SMPTE time-code an
   accurate clock;  in the first case, it runs slow, and in the second,
   the adjustments are abrupt and periodic - and still not quite
   accurate.


Abrupt and periodic are both OK, but if over long periods of time,
if there's going to be a systematic slip of the RTP time base relative
to the SMPTE time base in the case of NTSC ... I could imagine that
being a problem in some applications.

Is there a standardized way to do a second-order adjustment
on top of the drop-frame adjustment, to make the timing perfect over
long periods of time?  Or is the standard method to make "nominal"
"real-time" conform to SMPTE time, sort of how we drop a second
or add a second from "official time" on New Years Eve every few years?

I need to do some research on this one. Glenn Adams sent me this since we're discussing these time-codes also in the W3C. Quoted here without his permission:

* * *

I found an answer to this question in Timecode, A User's Guide, by John Ratcliff, 1999, on pg 58 (a book which I recalled having in my library but having never read before - looks like it is about time to read it):

"? the NTSC frame rate is not exactly 29.97 Hz: it is 29.970 026 17 Hz. This difference results in a long-term residual discrepancy of 0.000 026 17 * 60 * 60 * 24 = 2.261 frames over a 24 hour period, equivalent to 86.4 µs. Good operational practice requires that the timecode generator be reset at regular intervals if long-term errors are not to accumulate. Commercial timecode generators are available which allow the 86 µs discrepancy to be corrected at a time when least disruption to programme making will occur. The correction is made daily, automatically, and at a time programmable by the user."

However, this raises a new question since:

30000/1001 = 29.970029997002997? is not equal to 29.97002617 cited above

Having just done a little bit more research, it turns out that the 29.97002617 is correct, and is derived as follows:

Horizontal Scanning Frequency (lines/sec) / 525 (lines/frame) where

Horizontal Scanning Frequency = Chrominance Sub-Carrier * 2/455

Now, since Chrominance Sub-Carrier for NTSC is exactly 3,579,545Hz, then doing the arithmetic one ends up with:

( 3,579,545Hz * 2/455 ) lines/sec / 525 lines/frame = 29.970026164311878597592883307169 frames/sec

Note that this is still not quite 29.97002617, which seems to be a result of rounding up at the 10 parts per billion resolution.

So I guess the final conclusion is that the exact frame rate for NTSC turns out NOT to be 30000/1001, but rather to be 7159090/238875, which can be reduced to 1431818/47775.

* * * * * *


Is anyone in enough pain yet?
--
David Singer
Apple Computer/QuickTime

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt