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

From: "Miller, William C" <[email-masked]>
Date: Fri, 25 Feb 2005 10:47:05 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Singer
Sent: Thursday, February 24, 2005 4:01 AM
To: Chuck Harrison
Cc: lazzaro; Colin Perkins; Link, Brian; [email-masked]; [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: lazzaro <[email-masked]>
Date: Fri, 25 Feb 2005 11:26:56 -0800

On Feb 25, 2005, at 10:47 AM, Miller, William C wrote:
> 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.

[...]

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

Maybe part of the problem we need to address in AVT is
to decide just what function(s) we're adding SMPTE to
RTP to do.  Adapting your classification scheme.  I tend to
think in terms of three functions:

Labelling:  What I believe Brian Link was interested in
for his mastering application -- SMPTE was used as
a label to associate AC-3 frames with video, as a
cross-check of integrity.

Synchronization:  My own personal interest -- how does
one integrate RTP streams into an existing studio where
SMPTE and MTC and MIDI sequencer beats are the ways
different boxes in the studio think about sync?  Integrating
RTP means adding SMPTE so that these legacy boxes
can use the SMPTE timecode for sync.  Latencies may
be in the single-millisecond level (a human hitting play/stop),
timecode can roll forward and backwards (rewind), etc.

Timekeeping:  I'd guess David Singer's interest lies partially
in this direction -- if one is interested in a long-running RTP
stream (hours, days) for content distribution, one wants
SMPTE to be accurate as a timekeeper during those long
time periods.

If AVT wants to address applications that use all three
uses of SMPTE, the scheme we come up with
needs to work for all of them.  If we're only interested in
one or two of these three uses ... our job is easier.

Generally speaking, I'd feel more comfortable thinking
about this problem inside of AVT if there were actually
(more) product designers from NAB/AES/NAMM-exhibiting
companies playing an active role in AVT, with an interest in
using what we come up with.  Without that, there is a
lot of guesswork about potential applications going on ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 26 Feb 2005 10:39:38 -0500

Hello;

> 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/time…

Leap seconds are likely to go away in the relatively near future
(I used to be part of the process of setting them). They were created so that
UTC would stay within +- 0.6 seconds or so of "Earth time" (UT1), so
that someone
on a boat with a a sextant and a clock set to UTC could navigate 
to within a few hundred meters in longitude.
Since there is basically no demand for this in the currently GPS
saturated world, and
since they cause this sort of pain all over the place, they are on the way out.

Can't give a date, though. These wheels grind slow.

Regards
Marshall Eubanks