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

["Miller, William C" <William.C.Miller at abc.com>]

Dave, Chuck et al,

SMPTE time code was not intended to be used for timekeeping, though it's common in some facilities to do so with a jam sync once a day.  It's a label, intended to uniquely identify every frame on a reel of videotape so that editing and cuing could be automated; hence the name "time and control code".  The drop-frame algorithm is accurate enough for use with two-hour reels, assuming the station's sync generator is operating at the correct frquency.

Nominal NTSC carrier frequency is 3,579,545.454545... Hz.  The precise frequency is (455/2) * (525/2) * (60/1.001), or 5.000000... MHz * (63/88)(see SMPTE 170M, the authoritative reference for NTSC).  The latter formula is what's usually used to synthesize subcarrier from a rubidium or cesium standard.

Historical note:  The original intent of NTSC II, the committee working on compatible color, was to maintain the frame rate at 60.00 Hz.  However, in order to minimize visibility of the audio carrier in the received picture, it was necessary to shift its frequency to 4.5045 MHz above video carrier instead of precisely 4.5 MHz.  This would have caused problems with few existing B&W receivers.   However, there were some receiver manufacturers who, for reasons of cost, had implemented simpler audio receiving circuits that would have been adversely impacted by the 0.1% shift, and the FCC ruled that for the sake of backward compatibility the video frequencies (subcarrier, vertical and horizontal) were to be shifted down by 0.1% instead.  Apparently nobody ever considered that rolling hum bars would be far worse impairments than the audio distortion caused by having the FM discriminator circuit run slightly off center.  We've been paying the price ever since.

It is worth mentioning that SMPTE 12M is (still) under revision; the process has been long and painful but we do see light at the end of the tunnel.  Much of the pain has been due to the label/timekeeping dichotomy; it is nigh impossible to add accurate timekeeping capability to the standard without breaking backwards compatibility.  For instance, current 12M readers and generators have no ability to deal with a 59- or 61-second minute; these are needed to accommodate leap seconds, those periodic adjustments necessitated by the Earth's changing rotational speed.  Grandfather clauses and weasel words are necessary to handle these issues.

The chairman of the SMPTE ad hoc group that's revising SMPTE 12M is Pat Waddell of Harmonic; he's on the cc list above if you want to contact him.

Best regards,
Bill Miller


-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Dave Singer
Sent: Thursday, February 24, 2005 4:01 AM
To: Chuck Harrison
Cc: lazzaro; Colin Perkins; Link, Brian; lazzaro at cs.berkeley.edu; avt at ietf.org
Subject: [AVT] Re: 30/1.001 frames per sec [was: Carrying SMPTE time-codes in RTP streams, discussion email


Chuck

many thanks.  It strikes me that it may not be 
important whether we're off by a small factor in 
the NTSC clock rate, as in any case it counts 
actual frames, and it's possible that the source 
video clock is off by a small factor anyway. 
Clocks that drift with respect to each other are 
part of the joy of distributed multimedia.


At 8:47 PM -0800 2/23/05, Chuck Harrison wrote:
>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


-- 
David Singer
Apple Computer/QuickTime

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

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