SMPTE module?

[Jeff Koftinoff]

This is a bit incorrect - SMPTE (Society for Motion Picture and Television
Engineers) time code is more complex.

There are 'frames' as well as 'fields' - In NTSC there are two 'fields' per
frame doing interlacing.

So the time code is specified in Hours, Minutes, Seconds, Frames,
Sub-frames, and format.

Sometimes equipment is designed to use 80 sub-frames - sometimes 100. The
reason for 80 is because there are 80 bits of data stored in the audio track
per frame, containing the entire time stamp.

Different technologies use different number of frames per second. a normal
film/movie is played back at 24 frames per second. PAL video encoding uses
25 frames per second. Old black&white video uses 30 frames per second. NTSC
video encoding uses 29.97 frames per second so it can add color information
and still be compatible with black&white.

So we have different formats of SMPTE. The structure holding a smpte time
should also include the format.

It is not good enough just to store the frames per second.  There is also a
flag to enable 'drop frame mode'. So with NTSC video the format word would
specify 30 frame per second and drop frame mode.

Drop frame mode is the 'leap year' kind of calculation, dropping frames so
that the time specified matches the clock on the wall.

Drop frame mode specifies a single frame is to be skipped every minute,
EXCEPT every ten minutes.

So doing real calculations with smpte times is kind of hard - you can't just
add/subtract them normally when using drop-frame mode.

I have written proprietary code in C++ and C for handling this, and I'm only
starting to get involved with python and I haven't done it in python yet.

Probably the easiest thing would be to try find a book that specifies the
math that is required and just make your own smpte class from those
equations.

Best Regards
jeff koftinoff

Warren 'The Howdy Man' Ockrassa wrote:

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

--
Jeff Koftinoff
http://www.jdkoftinoff.com/