It is SMPTE's 100th anniversary! I hope that all readers have had a chance to view the Centennial Video (https://www.youtube.com/watch?v=jN2yYrEFMFQ) and to contemplate that 100 years ago we were in the dawn of the cinema era, where different equipment used different frame rates, different sprocket sizes, different frame sizes and the concept of distributing and delivering content between different manufacturers was a real headache.

Now, 100 years later and after a century of standardisation, we find our beloved Serial Digital Interface being replaced or augmented by (?) Internet Protocol (IP) transport. We find that the concept of black & burst timing synchronisation doesn't fit well with the concepts of IP. The prospects of synchronising pictures and sound recorded separately with a wide variety of frame rates and sample rates which in turn might be independently delivered via stream, file, point-to-point link or packetized network, have moved us full circle to "Needing a standard to sort this out".

If only things were as simple as they were 100 years ago. Back then the requirements were very basic because there was essentially no interchange of moving imagery unless you were playing back content on the same equipment that you shot it with. Today, there are many conflicting requirements. Let's take a simple example:

1. A new timing system must be simple

2. A new timing system must cope with all existing broadcast formats

3. A new timing system must cope with new frame and sample rates

These requirements all seem sensible. Requirement #1 implies that it should be easy enough to understand and implement - no complaints there. Requirement #2 is pretty straightforward as well. Timecode currently satisfies requirement #2, so if we're going to replace it then it would seem sensible to be able to use old content on a new system. Requirement #3 also appears pretty sensible. We are beginning to see cinema content at 120 frames/sec. We are seeing TV content between 24 frames/sec and 300 frames/sec . Varispeed content could be shot at any framerate. Wouldn't it be nice to be able to independently set up the camera and a separate sound recording device for object based (immersive) audio and have them magically synchronise themselves without a complicated setup procedure? Unfortunately, without limiting the ranges of frame rates and sample rates, you can't do it and still have a generally applicable and SIMPLE standard.

None of these initiatives are actually concerned with the core subject of synchronisation. For that, we need to look at the core SMPTE ST 2059 standard. This standard uses Precision Time Protocol (PTP) to distribute a time signal around a network so that independent devices can recover the same clock and know what the local time is to great accuracy. The system work by sending messages between nodes and measuring delays using local and remote clock references.

To build a complete system, legacy timing signals need to be created from the new timing source. Part 1 of the specification (SMPTE ST 2059-1 Generation and Alignment of Interface Signals to the SMPTE Epoch) allows this backwards compatibility to be achieved.

Then what of a replacement for timecode? That's where you come in. There are a number of emerging technical proposals, although what's actually lacking is a comprehensive set of user requirements. SMPTE has a tentative plan to coordinate a small number of Timecode Summits to gather requirements towards the end of 2016. If you're interested in being part of the development of requirements to help make the new timing system work for you then please contact Howard Lukk, SMPTE Director of Engineering and Standards via: https://www.smpte.org/smpte/79079/contact