LOS ANGELES—If you’ve spent more than a microsecond in TV, you know something about time code. It seems to have always been around and indispensable to TV production. Whether it is used as a time reference on recordings, on an edit time line or part of a program delivery format, time code is ever present.
There was a time before SMPTE TC (B.S.TC). These were dark days of using film (foot and frame counts) or basic control track tick marks or just a stopwatch. We’ve grown up with SMPTE ST 12-1 (originally ANSI C98.12.1975), but what is time code exactly? I’d like to give some background and then discuss new methods that will replace ST 12-1 in the not too distant future.
COUNTING FRAMES
First and foremost, ST 12-1 is a counter. At its base, it counts frames of video (not fields per se) as well as relates these frame counts to wall clock time, either absolute or relative. Born of videotape editing requirements, the first version of SMPTE TC was a linear signal, designed to be recorded on an analog audio track of a videotape machine. Limited to just 80 bits of data, the format is a bit arcane, using truncated BCD (binary coded decimal) notation for the frame counts and time values (H:M:S:Fr) along with some flag bits while the leftover bits were assigned as “user bits.” One important flag bit that is still in use today is the field bit. The field flag bit indicates the “phase” of the field cadence, where zero can mean either the top field (25Hz systems) or the bottom field (30Hz) systems and 1 means the other field in the sequence. In a revision of ST 12-1, the field flag has been defined for progressive video systems to increase the frame count to either 50Hz or 60Hz.
User bits have been assigned in public documents as well as for private use. One has to be very careful in using user bits, because their meaning can change depending on the context of the project.
As time went on, linear time code gave way to Vertical Interval Time Code (‘VITC’). Originally VITC was an analog waveform, superimposed on an active line in the vertical blanking interval of a TV signal. VITC was present in both fields of an interlaced video signal.
As video became digital, it was somewhat awkward to digitize an analog wave form of a digital data stream. So, a variant of VITC, called Digital Vertical Interval Time Code(DVITC) was developed. Because component digital video signals did not have a vertical interval, time code had to be re-packaged as pure data into the Vertical Ancillary Data Space (VANC) but formatted to “look like” video samples.
Then along came file formats. Here time code would be decoded to binary code values, sometimes converted to different formats, and then embedded into files, either as a “time code track” or in the header/footer of a media file. MPEG transport streams can also embed time code in the ancillary packet header of a MPEG TS packet, thus time code and compressed video can be distributed either as a bit-stream or as a file type.
Recently, SMPTE ST 12-1 was extended to provide frame counts above 60Hz. This is now documented as ST 12-3, and uses some of the binary flag bits as a modulo counter of “sub-frames” that are extensions of the classic “super-frames:” 24, 25, and 30. Thus any frame rate that is a multiple of 24, 25 and 30 can be extended using the five binary flags, for maximum frame count of 960 (30x32).
Okay, you may have noticed that I have not discussed “drop frame” time code. So not to go too deep into the ancient reasons why in NTSC countries the frame rate is really 29.97Hz (30*1000/1001), this causes a disconnect between the time code, time values and the real time clock time. The accumulated error is approx. 3.6 seconds per hour or 1.5 min per day. To compensate for this error, SMPTE ST 12-1 defines a special counting of frames that “skips” certain numerical frame counts on a regimented basis, so as to “catch up” to real time. While not perfect, there is residual error at the end of the day of about 86 mS or 2.59 frames, it is “good enough” to edit to time and deliver shows and commercials accurate well within a frame time. (By the way, drop frame time code is only corrected up to midnight. After midnight the error will accumulate unless a “jam-sync” is forced to reset the time code clock to real time. This has been acceptable practice for many years and most practitioners know that if there is a recording over midnight, there will be a time code jump (which usually is fixed by re-stripping the time code when ingested into an edit system).)
MODERN TIMEKEEPING
Starting back 10 or so years ago, some engineers thought of a better way to both synchronize video (and audio) as well as represent frame counts (or sample counts) and to have a system that is not only time accurate but in fact is traceable back to a master clock reference such as GPS.
First, some background on the nature of modern clocks as used in computer networks: You may be familiar with Network Time Protocol (NTP); this is the method that computers can sync their clocks over an IP network to a master clock. It works pretty well for conveying time with reasonable accuracy (~1-10 mS) but is not good enough for synchronization of video signals due to the variable latency present in IP networks. IEEE, realizing that the precision, accuracy and stability of NTP was not sufficient for critical real time applications, developed Precision Time Protocol. PTP or IEEE 1588 defines a protocol over IP as well as the requirements for master clocks (Grandmasters) and slave clocks. PTP provides accuracy and stability of timing (~0.1-10 uS) sufficient to synchronize video as well as audio and other signals.
Another important feature of PTP is the concept of an Epoch. An Epoch is a “start point” in time that defines the “zero” count. Time is then measured from the Epoch to the present using a precise frequency of any unit desired. One can use seconds, milliseconds, pico seconds or frames of video (with a defined frame time = 1/frame rate) or audio samples (1/sample rate). SMPTE has defined the Epoch to be Jan. 1, 1970, midnight Greenwhich Mean Time (GMT). Further, SMPTE has defined the “start point” of the Epoch to be the start of vertical sync reference for all formats and frame rates. The SMPTE ST 2059-2 defines the profile for the use of IEEE 1588 for Professional Broadcast Applications.
Thus by counting time from the Epoch, and knowing the exact frame time, one can determine the offset between two video signals, providing that each of the video signals were created while connected to a known PTP reference (see SMPTE ST 2059-1 Generation and Alignment of Interface Signals to the SMPTE Epoch). Of course it is not always possible to be connected to a reference, but we can always “time sync” and bring the unreferenced video back into alignment with the Epoch.
NEW TIME LABELS
Back to time code. The SMPTE standards committee for Time Labeling and Synchronization contemplated modifying ST 12-1 time code to carry some information to be able to tie back to PTP and the Epoch. While ST 12-1 time code has user bits and binary flag bits that could have been redefined, an exhaustive search for all the current (and legacy) use of these bits showed that this would be very disruptive. Further, this approach would be carrying forward a legacy of a digital signal coded for an analog world into an all-digital IP packet environment. So the committee decided to develop a new time code, based on PTP and the new video sync standard. The criteria they developed included:
§Simple
§Adaptable
§Human Readable
§Carry additional information
§Convertible to/from ST 12-1
§Packetized for delivery over SDI, IP, MPEG TS, etc.
§Stable and accurate over long periods (weeks, months, years)
Two approaches have been developed by the drafting groups. One is a called Generic Time Label (GTL) the other Time Related Label (TRL). These time labels represent a running count of media units such as video frames and audio samples, counting from a known time reference such as the SMPTE Epoch or a private Epoch. The difference between these time labels is that the GTL carries just the count along with rate and origin metadata. The TRL defines a set of objects that can be used to carry a variety of time code and label information as well as a media count. Both TRL or GTL time labels can be used to relate the media counts to real clock time and dates as well as legacy ST 12-1 Time Code values, however the TRL allows for the direct embedding of these alternate formats within the label as well as additional metadata related to the media, including legacy ST 12-1 flags and binary groups. For both TRL and GTL the underlying time reference is based on the ST 2059 SMPTE PTP standard.
Recently Howard Lukk, the new SMPTE Director of Standards, organized three “summit” meetings, one each in Los Angeles, London and New York. The purpose of these meetings was to gather input from the user community with regards to their needs for a new time label. For those that could not attend, you can take the time label survey at www.SMPTE.com/timecode.
So we’ll have ST 12-1 Time Code around for the foreseeable future, but be ready to deal with these new time labels as well as the new SMPTE ST 2059 time and sync reference standard based on IEEE 1588 Precision Time Protocols.
Jim DeFilippis is CEO of TMS Consulting, Inc., in Los Angeles. He can be reached atJimD@TechnologyMadeSimple.pro. See more at hisauthor archive.
