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

[Marshall Eubanks <marshall.eubanks at gmail.com>]

Hello;

On Fri, 25 Feb 2005 10:47:05 -0800, Miller, William C
<William.C.Miller at abc.com> wrote:
> 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.
> 

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


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

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