Accurate representation of time in broadcast stations is fundamental to operating an efficient network. Playout schedules using automated delivery systems require frame accurate timing information for switching between programs and Ad breaks, inserting voice-overs and triggering affiliate opt-outs.

In NTSC Line and Frame Relationships, we looked at why the American NTSC system still uses 59.94 fields per second. Standard and high definition also uses 59.94i in the USA and any countries that have adopted their system. Europe and the UK continues to use a field rate of 50i fields per second.

In broadcasting, each video frame is counted to give a measure of hours, minutes, seconds and frames. In European systems this is easier as there is a simple integer relationship between the number of frames and a minute, that is, there are exactly 25 frames in one minute, so each frame measures 40 milliseconds. In one minute there are 25 frames x 60 seconds = 1,500 frames, and in one day 25 frames x 60 seconds x 60 minutes x 24 hours = 2,160,000 frames.

This measure is referred to as timecode and has the following format – two digits for the hours, two digits for the minutes, two digits for the seconds and two digits for the frames. For example, the following characters 12:04:30:00 describes the time four minutes and thirty seconds past midday.

Frame counts start at 00 and end at 24 for the European 25 frames per second and start at 00 and end at 29 for USA 29.97 frames per second. The hours use the 24-hour clock and start at 00 for midnight all the way through to 23 for the hour just before midnight. And minutes start at 00 and run through to 59. The first time of the day is 00:00:00:00 for both USA and European systems, and the last time of the day is 23:59:59:24 for European systems and 23:59:59:29 for USA systems.

Time is Complex in 59.94

For systems using the USA’s 59.94 fields per second, or 29.97 frames per second, counting time is much more complex. The figure 29.97 is the rounded off equivalent of 30/1.001 as described in the article – NTSC Line and Frame Relationships.

If this was left unadjusted, the time on the video playout server or tape player would be running slower than the wall clock by approximately 0.1% as there are less frames in an hour at 30/1.001 fps than at 30fps.

To put this into perspective, if the USA system used 30fps then there would be 108,000 frames in 60 minutes, that is 60 secs x 60 mins x 30 fps. However, as the frame rate is running at 30/1.001 fps, the number of frames per hour played from the server is 60 secs x 60 mins x 30/1.001 fps = 107,892.1079 frames, a loss of 107.8921 frames, just under 3.5 seconds an hour, or 1.5 minutes a day.

Minutes are Lost Each Day

It’s common for broadcasters to use frame-count as their reference for program and edit timing. However, using 30/1.001 fps means we loose 1.5 minutes per day from our programming schedule. This would be completely unacceptable as Ad-breaks would be crashed and revenue lost.

To fix the timing difference, the Society of Motion Picture and Television Engineers (SMPTE) developed a system called drop-frame-timecode. It’s important to remember, that there are no video frames dropped or lost but instead the count of frames is adjusted to correct the ambiguity between the wall clock and frame-count time.

Drop Frame Timecode

The objective of drop-frame-timecode is to align the frame count with time of day on the station wall clock so that playout schedules and edit systems continue to operate without error. To achieve this, SMPTE created an algorithm which works as follows;

1. Timecode skips frames 0 and 1 of the first second of every minute, unless…..
2. The number of minutes is divisible by 10, then the values are not changed

Adjacent frames 0 and 1 were chosen as the frames to “drop”, as program editors like to cut between frames and not fields to give more fluid motion and better continuity.

As an example, the following sequence shows dropped frames;

• 07:08:59:28
• 07:08:59:29
• 07:08:00:02
• 07:08:00:03

The time count jumps between the second and third samples.

For every tenth minute, the sequence is as follows;

• 07:09:59:28
• 07:09:59:29
• 07:10:00:00
• 07:10:00:01

As can be seen, there is no skip of time count between the second and third samples.

Although the count sequence is being modified, the actual video and audio samples are not being deleted, instead, we are just modifying the reference count so if a server is played at the beginning of the day, its time count will match the wall clock throughout the day.

Time Discrepancy 

However, even using this system, there is still a small discrepancy between timecode and the wall clock at the end of the day, and consequently the engineers must re-sync the timecode master clock periodically.

The same is true when daylight saving changes occur. Engineers will adjust the timecode master generator at midnight to reflect the new time. This can cause problems for 24/7 playout centers and any such changes must only be conducted after the appropriate change control procedures have been completed.

In broadcast centers, the timecode generator is referenced from the sync-pulse black-and-burst generator to maintain accurate frame counting and time keeping for the station. Clocks receive a feed of the timecode so production crews, presenters and technicians all have the same accurate time reference.

VITC and LTC

Timecode signals are distributed in two forms – longitudinal Timecode (LTC) and Vertical Interval Timecode (VITC). In analog systems, LTC is distributed using twisted pair audio cables. Data clocks are encoded within the signal and the resulting stream fits within the bandwidth of an audio signal, so timecode data can be distributed throughout the broadcast center.

VITC contains the same timing information as LTC but is inserted into the frame blanking of the video signal to guarantee frame accuracy. Lines that are not in-vision are used as the VITC data appear as white dots and must be kept in field blanking to not disturb the viewer.

Beware of Compression 

Although VITC is considered an effective way of accurately identifying each frame, the information is usually stripped from the video signal when its encoded by compression, such as MPEG2 or HEVC, and the codec must be configured correctly so the VITC is maintained and re-synchronized with the video after it has been delayed by compression.

Timecode in USA 59.94i and European 50i systems is handled differently due to the inherent discrepancy that is evident in the USA system caused by the reduction of frames in each second from the 30/1.001 frame rate. Drop-frame-timecode rectifies this but it’s important to remember that video frames and audio samples are not deleted, instead the SMPTE specification describes the adjustment of the time count to keep it synchronous with time of day.