SMPTE module?

[Warren 'The Howdy Man' Ockrassa]

[posted and mailed -- WthmO]

Erik van Blokland wrote:

> I've looked around for some python code that does SMPTE time code
> calculations, but could not find any references anywhere. I'm thinking
> some sort of timecode tuple (18, 2, 34, 33) -> float(seconds) and back,
> and perhaps some adding and substracting.

May not hurt to amplify on what SMPTE is. Based on my recollection of
it, your tuple would be rendered as SMPTE

  18 hrs 2 min 34 sec 33 fields

...but it's the "fields" parameter which needs some amplification. (The
rest is easy, of course.)

This (SMPTE) is a reference to time code used in timecode-capable video
editing tape controllers and video decks; it is much more precise than
analog frame or field counting and is in use, more or less, all over the
planet in video editing systems, not all of which are directly
interfaced to computers, but effectively all of which are digital now.

Here's the basic rundown, for those unfamiliar with video editing
standards and their reasonings, to the best of my arguably-addled
recollection. (I am not trying to show off here; I think this technical
background is necessary to answering the question from the perspective
of *NIX hackers who've never necessarily cared a whit about broadcast
television video engineering. With any luck this lengthy treatise can
bridge terminology enough to get the point across and get the question
answered, partly at least because I would like to see a solution to this
as well for future reference! Besides, I am surely wrong about some of
this. That's not showing off anything save my own ignorance. ;)

Video "frames" are composed, on videotape, of two "fields", or
half-scans of the video tape and the monitor, as read/written by the
helical scan video play/record head, said scans coming off the tape as
roughly diagonal lines.

This frame/field idea is similar in concept to the IBM 8514 monitor
standard which gives you 43.5 Hz of actual scan, broken into 87 Hz
interlaced fields, at 1024 by 768 resolution, for those of you who have
ever tried to get this kind of display working under XWin on Linux.

Those of you who have been inside a VCR have seen this head unit to
which I am obliquely referring; it is the diagonally-canted, highly
polished drum past which your videotape plays. It usually has two read
heads in it, 180 degrees opposed to each other, which actually read the
video striping off the tape as it trawls past. The drum itself spins at
about 1800 RPM in the US when the VCR is up to speed (assuming my math
is up to speed). Rationale:

  2 heads (fields) = 1 scan; 2 heads pass 1/30 sec.
  1/30 sec = 1 frame
  30 frames = 1 sec
  thus 30 complete rotations = 1 sec
  60 secs/minute; ergo
  1800 rotations/minute

Helical scanning effectively permits emulation of a *very* fast tape
speed past the read/write heads, improving the fidelity of both the
video and -- in the case of HiFi -- audio signals. (I believe modern
computer tape backup drives use a similar helical scan method, the tape
speed locked there, as it is in video, by a linear sync pulse track.)

A linear tape which ran past the heads at an equivalent rate would have
to be massive, perhaps hundreds of Km of tape for one single 1-hour
recording, assuming identical signal fidelity.

[This also explains why a straight cut and splice of a video tape that
has been damaged will give you disastrous playback results -- your video
picture will roll and flutter for about 5 to 10 seconds at the splice
point as the sync pulse tries to match step with the severed diagonal
lines in the broken helical scan pattern, and don't even get me started
on how hard it used to be to edit video tape manually. Short answer:
Surface developer, a microscope and a razor blade. Really.]

ANYway.

Video "frames", as implied, are composed of the information gathered by
two "fields", each of which is collected by one of the heads as it spins
past the tape in the head assembly, and are highly dependent, among
other things, upon the frequency of the AC pulse passed to the
television monitor which displays the two fields interlaced onscreen as
one video frame, itself running off the Hertz standard of the AC line
supplying its power. (This is why, for instance, a PAL tape from Denmark
will not play properly in a VCR in the US, and vice versa. The sync
pulses from the tape do not match what the TV is trying to display,
basically.)

There is an obvious problem -- two actually. The NTSC standard used
primarily in the Americas and Japan relies upon a Hertz (field) rate of
60, which means there are 30 frames in a video second, while the PAL
standard used throughout Europe is centered on a 50 Hz pulse, rendering
25 frames in a video second.

But the 60 Hz cycle in the US is an *approximation* of the video sync
rate, just as the 25 Hz measure is in Europe, as I recall.

30 frames per second for NTSC -- Americas -- doesn't go well in a system
which is not in fact precisely 60 Hz, which means effectively that
sometimes frames have to be "dropped" to round things to the correct
integer; as I recall a similar situation exists for PAL. (AC pulse, in
the US, is not precisely 60 -- it's 59 decimal something.)

As I recall too the film standard of 24 frames per second for cinema
footage is a factor, but my recollection gets hazy at that point, beyond
remembering that PAL film-to-tape is superior to NTSC because of a
closer initial frame rate, coupled with the fact NTSC is good for about
330 lines of resolution, while PAL is more like 425. (More lines ==
higher image quality.)

I think it's both, really, here in the US. You lose 1 frame for every 5
to sync down to 24 frames/second for film-to-tape, and lose an
*addtional* frame every few (ten?) hours to sync down with the
not-quite-60Hz pulse rate.

Astoundingly, this is SMPTE. Why? It started here first. So naturally we
assume the rest of the world will dumb down to us, even if what we are
doing seems weird or illogical; call it American hubris. (Just like
miles make sense to us, while most Americans get a headache when
contemplating the Metric system. 5280 feet per mile somehow is more
reasonable to an American than 1000M to a Km. Go fig!)

What this *really* means is that there are two methods (within any one
national standard!) of timing video tape segments, a "raw" format (also
known as "control track"; it relies on a small linear track recorded on
the tape along with the helical scans; this is the "tracking" you adjust
sometimes on your VCR) and, in the Americas at least, an SMPTE
drop-frame format which, occasionally, kicks out an extra video frame
from its calculations, a sort of leap second, recorded in a similar
fashion to the control track, but with much more precise timing. (Well,
leap 1/30th second.)

In fact if you ever cross your SMPTE track with your audio playback, you
will hear -- very loudly -- a pulse not unlike what your modem does when
it is matching connection as you dial in to the net. For similar reasons
-- the SMPTE track is basically an analog version of a digital sync
frequency.

I don't recall the specific intervals but believe it's hardcoded by
SMPTE standard under the NTSC convention to one dropframe every 5
seconds. (It has been a while since I cut tape!) I have no recollecion
if this drop frame interval maps isomorphically to the PAL standard or
not, but I think it does.

What this means is that 5 seconds of video is not 150 frames US (300
fields); it's 149. The last frame is lost as a leap frame.

Thus the question is probably something like

  I need to define a way of slicing up seconds into more or less
  even intervals of either 1/25 or 1/30 second, but need to arbitratily
drop
  one of those fractions every five iterations or one every 25,
depending
  on the Hz and the standard; is there a module which does
  this, or is there a method by which it an be achieved?

Of course it would help to know if this has to be locked to 60 Hz or 50
Hz, and what the precise decimal measures are. ;) SMPTE implies 30.

Here in the US, for instance, one tuple could be something like

  18, 2, 34, 30, 50

or

  18 hrs 2 mins 34 sec 30 fields scanned 50 percent fields total this
sec

where 50 is 15 fields (scan percentage), unless your seconds were an
even multiple of 5, in which case 50 would I believe be 52; of course if
your minutes were even multiples of ten you'd have another drop frame to
consider.

Are we having fun yet?

I could definitely help you out if you were working in Director, Erik,
and knew if you were standardizing to the NTSC pulse or the PAL one, but
I am absolutely fresh to Python so, while I know beyond a shadow of a
doubt that what you are asking is entirely possible, I am entirely
ignorant of the syntax required to get you going with it. :(

Hopefully this expansion is of value...

--
    warren ockrassa | nightwares | mailto:warren at nightwares.com
                    http://www.nightwares.com/

PS: Glossary:

SMPTE: Society of Motion Picture and Television Engineers
NTSC: National Television Standards Code (jocularly, Never The Same
Color)
PAL: Phased Alternating Line (Interlaced scan!)

There is a third video standard in use, SECAM, for Sequential Color And
Memory, but (as I recall) it's mostly used on Communist-bloc nations and
former Communist regimes. I don't know any of its parameters, and
suspect it never standardized to (or even looked at) PAL or NTSC, let
alone SMPTE. Nevertheless if one wants to make a portable video pulse
reader, perhaps the SECAM standard is worth looking into as well.