This document explains the four meanings of "timecode," and refers you to SGI software that helps you manipulate these forms of timecode where relevant.
typedef struct {
int hour;
int minute;
int second;
int frame;
int tc_type;
} DMtimecode;
The tc_type field (discussed in tc_type(3dm)) tells you the signal
type (whether 24 or 29 is the maximum "frame" value), and whether the
timecode is drop-frame. You pretty much always want to use one of
these values for tc_type:
Drop-Frame Timecode
Above we told you that the "frames" field of 60000/1001 field per
second video ranged from 00 to 29. This is true, but there is a catch.
The 60000/1001 field rate tells us that there are 30000/1001 frames
per second, but having 30 possible values for "frames" implies 30
frames per second. As a result, the timecode does not accurately
reflect hours, minutes, seconds, and frames of real time!
For example, say you're capturing NTSC video, and you assign each incoming frame a timecode which is one frame higher than that of the previous frame. Say you start this process with timecode 00:00:00:00 and stop when you get to timecode 01:00:00:00. You recorded one hour of video, right? Wrong. You recorded 60*60*30 frames at 30000/1001 frames per second, which is 1 hour and 1.001 frames of material. If you are trying to produce a clip of an exact length (for insertion into other material or synchronization with an audio track, for example), you must often be aware of the distinction.
If you never need to take large differences between timecodes and interpret them as real-time (for example, if all your material is very short), then these disparities might not matter. Using all 30 values of the "frame" field like any sane person would is called "non-drop-frame timecode."
However, if you have long material, you may need to use "drop-frame 525/29.97 timecode." This is a numbering scheme where "frames" still goes between 0 and 29, but where you purposely skip a certain, standard set of hours:minutes:seconds:frames combinations. You skip the first two frame numbers (0,1) at the start of each minute, except minutes 0, 10, 20, 30, 40, and 50. No video data is dropped: you merely assign timecodes that sometimes increment by more than one frame to subsequent frames of video data.
Drop-frame 525/29.97 timecode gives you an average of 29.97 frames per second. This is imperfect (29.97 is not equal to 30000/1001), but it is a lot closer than 30. Drop-frame 525/29.97 timecode will give you an error of two frames per day, compared to 24 for non-drop-frame timecode. Studios take it as part of their regular operating procedure to reset their timecode generators occasionally, and to never trust timecode intervals longer than about 12 hours.
625/29.97 is another kind of drop-frame timecode used only for M-PAL (an NTSC-rate video signal based on PAL encoding, used in Brazil). The standard set of frames to drop is different than with "drop-frame 525/29.97 timecode" (the resulting rate is still 29.97). But no current SGI device supports M-PAL.
For the specifics of exactly which frames are dropped in a given, drop-frame code (and why), check out the Ratcliff book cited below.
Some of the more important over-the-wire timecode signals are:
LTC, sometimes ambiguously referred to as SMPTE time code, is a self-clocking signal defined separately for 525- and 625-line signals. The signal occupies its own channel and resembles an audio signal in voltage and bandwidth. LTC is the most common choice for situations where you want to slave one machine's transport to that of another machine (in the sense that both machines will be on the same frame, not in the sense that the signals on both machines will be genlocked). In a LTC signal, there is one codeword for each video frame. The corresponding video signal is present on some other wire. The codeword contains a timecode, 32 "user" bits (see VITC below), and some other useful information (such as whether or not the timecode in the codeword is drop-frame). In some audio and MIDI applications, LTC is useful even though there is no video signal.
SGI ships a LTC parser in libdmedia (see dmLTC(3dm)) which you can use to parse a LTC waveform out of an audio stream. Please see ltc.c for sample code.
SGI also ships some free sample code of LTC parsing in dmedia_dev.src.examples at /usr/share/src/dmedia/timecode/ltc.
VITC timecode is a standardized part of a 525- or 625-line video signal. The code itself occupies some lines in the vertical blanking interval of each field of the video signal (not normally visible on monitors). Each VITC codeword contains a timecode, 32 "user bits" as with LTC, an F1/F2 field indicator, and some other useful information (such as whether the timecode in the codeword is drop-frame). People use the user bits to store information such as reel and shot number. This information can be used to help index footage after it is shot. Under the right circumstances (not always trivial), the original VITC that is recorded with footage can even "tag along" with that footage as it is edited, allowing one to produce an edit list or track assets given a final prototype edit.
SGI ships a VITC parser in libdmedia (see dmVITC(3dm)) which you can use to parse a VITC image out of a pixel buffer. Please see vitc.c for sample code.
In the audio world, production studios often need to synchronize the transports of computers with the transports of multitrack audio tape recorders and dedicated MIDI sequencers. Sometimes LTC is used for this, and sometimes MIDI time code is the clock signal of choice. MIDI time code is part of the standard MIDI protocol, which is carried over a serial link that is also called MIDI. SGI machines connect to MIDI via a MIDI dongle that connects to the serial port of the SGI machine.
You can use the SGI MIDI library to send and receive MIDI time code messages.
Another common timecode signal in the audio world, especially in production studio situations not involving MIDI sequencers, is (silent) AES digital audio---the very same signal generated by Indigo, Indy, Indigo2, Onyx, Onyx2, Challenge, Origin and Octane systems. The AES standard allows one to embed timecodes in the audio signal, so this is often perfect for multitrack tape decks with digital inputs. SGI may add AL support in the future to let you input and output the subcode bits.
Some video tape formats include extra tracks for the storage of timecode. Sometimes, timecode is stored on audio tracks of video tapes. This on-tape timecode signal often mimics an over-the-wire timecode signal, as is the case for LTC. Sometimes the on-tape format is totally proprietary, as with Hi8's RC time code track; in these cases there is often a deck option to translate the proprietary on-tape signal to and from a standard over-the-wire timecode signal. In addition, almost any deck is capable of storing and retrieving VITC since it is part of the video signal, and LTC can be stored on any audio track.
Some of the new consumer-level deck control protocols function on decks that do not store unique per-frame timecodes with each frame (or field). Therefore these systems have limited accuracy for deck control applications.
Get yourself a copy of ANSI/SMPTE 12M-1986 for information on LTC, VITC, and drop-frame 525/29.97 timecode.
"Time Code: A User's Guide" by Ratcliff (Oxford: Focal Press, 1993) provides excellent details and history on 525-, 625-line, and film timecodes. It has a good bibliography which points to other relevant standards documents. There is a more up-to-date version than the 1993 edition, so look for that.