SEATTLE—AWS has announced that AWS Elemental MediaLive now offers timecode burn-in so that users can add timecode visually into individual video outputs from a MediaLive channel.

While visual timecode is not generally used when delivering video to viewers, this feature is useful for testing, monitoring, and compliance. 

MediaLive allows configuration on an individual output basis, so users can separate audience delivered outputs from outputs with burned-in timecode for technical monitoring.  Timecode burn-in in MediaLive is available at no additional cost.

For more information on how to enable this feature, visit the MediaLive documentation for timecode configuration.

AWS Elemental MediaLive is a broadcast-grade live video processing service. It lets you create high-quality live video streams for delivery to broadcast televisions and internet-connected multiscreen devices, like connected TVs, tablets, smartphones, and set-top boxes.

The MediaLive service functions independently or as part of AWS Media Services, a family of services that form the foundation of cloud-based workflows and offer you the capabilities you need to transport, create, package, monetize, and deliver video. 

Visit the AWS region table for a full list of AWS Regions where AWS Elemental MediaLive is available.

Timecode vs. Genlock: Why timecode may not be enough to keep your set in sync

By Henri Rapp

The common assumption is that by feeding timecode to camera you will keep camera and sound in sync. Unfortunately this is not so, Timecode and Sync are not the same thing. Timecode is in fact only metadata to identify how the first frame is labeled for time when the camera begins rolling. Once a camera starts recording, it ignores external timecode and uses its own internal clock to record. The problem you get here is the camera clock is not calibrated to the external sound recorder’s clock, and slowly they will drift apart as you continue to record. This is especially problematic for productions that require a long roll time (30 minutes plus), such as Reality TV or Event Coverage. This can cause endless headaches in post when you match the audio and video with timecode, and by the end of the clip the video is noticeably out of sync with the audio. The solution here is Genlock.

What is Genlock?

Genlock originated in the early days of broadcast and video switching systems. Genlock was used to keep cameras, and other video sources’ frames in sync to avoid nasty artifacts introduced when switching from one source to another. These days most switchers can compensate for this rather than feeding black burst to every source from a central clock. In the HD world Genlock is still hanging around, but these days it uses a protocol called Tri-Level Sync to clock both the frame rate and line rate. This is especially important for 3D two camera rigs. Because Genlock clocks the capturing of frames on a camera, it can be used to keep the picture from drifting from the audio over time.

Keeping Set in Sync with Timecode, Genlock, & Word Clock

In order to keep every device in sync, you need to have everything clocked by one central master clock. The cameras need to be fed timecode and genlock, and the audio recorder needs timecode and word clock. I decided for my rig to use Timecode Systems :Wave Master Clock. This acts as a generator for Word Clock & Genlock and is slaved to my Sound Devices 664 for Timecode. With an additional 9 pin Lemo to USB data cable, I am able to control metadata, arm and disarm tracks, start and stop recording, and more on my Sound Devices recorder. The Timecode Systems UltraSync Ones get rejammed twice per second via 865 MHz to 923 MHz Worldwide ISM bands. Each camera gets an UltraSync One that outputs timecode and genlock keeping the camera perfectly in sync with everything else on set.

Common Cameras That Can Be Genlocked

Here is a few examples of commonly used cameras that can be Genlocked (Some, like the FS7 for example, require additional accessories to take Genlock and Timecode):

Arri: Arri Amira, Arri Alexa, Arri Alexa Mini

RED Digital Cinema: Red Weapon, Red Epic, Red Scarlet, & Red Raven

Sony: Sony FS7, Sony F5, Sony F55, & Sony F65

Canon: Canon C700, Canon C500, Canon C300 Mark II, & Canon C300 Mark I

Panasonic: Panasonic HPX-2000, Panasonic HPX-250, Panasonic P2HD, Panasonic Varicam 35

About The Author:

Henri Rapp is a Location Sound Recordist & Recording Studio Engineer in Cleveland, Ohio. When not out in the field I also do audio post-production for video and produce music out of Bad Racket Recording Studio in Cleveland.

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.