[AVT] 30/1.001 frames per sec [was: Carrying SMPTE time-codes in RTP streams, discussion email

[Chuck Harrison <cfharr at erols.com>]

Hiya,

Dave Singer wrote:
> 
> 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?
> 

There is a draft practice under standardization in SMPTE called
"Date Compensated Count" which addresses this issue. However
I think there is no panacea; in many cases the right answer is
"cheat at the time of night when the fewest people are watching".

There is also a SMPTE standard "Absolute Time Reference (ATR)"
which establishes precise relationships among timebases in
different production standards (NTSC, PAL, AES audio, etc.).
ATR also has a mechanism for leap second insertion; this is
necessary because the rotation of the earth -- represented
by UTC -- is not as stable as international atomic time
(TAI).

Not enough pain yet? Read on...

> 
> 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:

I do not think this statement is true. Most official
standards documents define NTSC frame rate as 30/1.001.
This would correspond to a Fsc of  3,579,545.4545... Hz.

As I recall the story, the reason the frame rate was pulled
0.1% down was to keep the TV sound carrier from beating with
some of the video signal components during over-air transmission.
When color TV was introduced it was determined that the zillions
of black-and-white sets already in homes would easily handle a
small change in scan rate but their tuned-circuit FM sound
demodulators wouldn't have tracked an 0.1% shift in carrier
frequency as nicely. "It seemed like a good idea at the time."

It seems fairly likely that a reference citing 3,579,545Hz
as the exact Fsc was simply rounding to an integer frequency.

It is equally possible that different official standards have
been independently published that disagree on this.

The only situations where sub-part-per-million precision
matters involve long-term accumulation (such as discussed at
the beginning of this email). I would stick with 30/1.001
for this because that's what all the recent SMPTE documents
in this area have been using. I've never heard of anyone
using the 3,579,545.00Hz-based number in this kind of work.

Cheers,
  Chuck Harrison
  Far Field Associates, LLC
  Seattle, WA

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