Progress Will be Outlined at Upcoming Tech Conference

It may be hard for anyone who works professionally with video to imagine it, but time code as we know it is about to change. Recognizing that innovations in digital acquisition and post have rendered the nearly 40-year-old approach to video time code obsolete, the process for defining a 21st-century standard for time code is well underway in SMPTE. That doesn't mean it's too late to have some say in the process – but you'd better hurry. A good place to start is the upcoming SMPTE Annual Tech Conference and Expo, slated to take place October 28-30 at the Renaissance Hollywood Hotel in Hollywood, CA. F&V contacted SMPTE Director of Engineering and Standards Peter Symes via phone and email for a Q&A on the progress being made on time code and synchronization standards, as well as a few related nuggets.
When did it start to become apparent that a new effort was required to re-standardize time code?

It was probably a gradual dawning over quite a period. We had been doing extensive work on the existing 12M standard to clarify some ambiguities, providing limited support for higher frame rates like 50p and 60p. But we had a conflict; there were those who really wanted to bring the standard up to date, versus those who didn’t want to change anything whatsoever that would affect backward compatibility. Those are both very laudable objectives, but basically incompatible. We decided to redraft the existing 12M standard, providing limited support for higher frame rates and making it a more readable and a carefully crafted document – but also making absolutely sure we kept backward compatibility. Then we took a clean sheet of paper and said, “All right, if we want to define a time-labeling scheme for the future – without worrying about backward compatibility except in limited areas – how would we do it, what would we like to see, and how can we create something that’s more versatile going forward?”

Going forward into the digital age, color-black [for sync generation] has got its limitations, too. It’s also a 30-year-old standard and has a number of limitations, particularly for production and post-production people who work in multiple formats. Again, if we were to take a clean sheet of paper, what’s the best way to do synchronization moving forward?

So there’s a tenuous link between them. They involve a similar thought process. But they’re nonetheless separate projects. We sat last year talking to our European Broadcasting Union [EBU] colleagues, and agreed, “This is really the right time to start doing this.” We’re not in a desperate situation; neither time code nor color-black is intrinsically broken. However, they’re both getting pretty long in the tooth. If we don’t do something about standards for the future we’ll probably start to see proprietary implementations appear, and that’s bad news for everybody. So we’re handling both of these issues in the same task force. We’ll be producing one output from the task force on synchronization and one on time-labeling, putting those over into the standards bodies, and hopefully coming up with some nice shiny new standards.

Do you have timetables in place?

We were initially hoping to wrap up the task force by the end of this year. I think on time code we may. On synchronization, we’re getting sufficiently radical in some of the ideas that we decided we need to do some verification and testing and get some prototypes built before we can provide a really credible output. We’ll probably run task-force meetings through at least until February or March 2009 and then pass the work over to the standards group. If we’ve done a good job in the task force we could have new standards by the end of 2009. We’ll be into late 2009 and early 2010 for the final documents.

What are the most important features of the new time code, or the fundamental differences in this version?

While recognizing what sterling service 12M time code has done – due to the ingenuity of both manufacturers and users – it was created by asking, “What can we record on the edge track of a two-inch tape and convey by an audio signal?” It’s a fairly inefficient usage of the data space. It’s an 80-bit package with only 64 bits used, and they’re used in an inefficient way to give you eight binary-coded decimal [BCD] numbers. It’s very much 1960s, 1970s thinking. But the real question is what things 12M doesn’t do. It’s limited to a 24-hour period. We’ve done extensions to put in date information, but they’re all sort of add-on kludges instead of fundamentally a part of the time value. It doesn’t support higher frame rates. We managed to get basic support for 50p and 60p, but again we’re looking at environments where much higher frame rates are being considered. Super slo-mo is going towards 300 fps. Scientific applications need a lot more than that. Drop Frame is a very limited solution to the problems of 59.94 and related frame rates. And there’s absolutely no support for overcranking and undercranking.

One of the minimum requirements was, assuming a time source was available, that on any source material we get an absolute acquisition time to a high precision so that if either everybody’s locked to GPS or everybody on site is locked to the same clock, – any element has got an absolutely unambiguous label saying this happened at the same instant as something with the same time value on it, whether you’ve overcranked or undercranked, if you’re at a different frame rate, no matter what sort of audio machines you were using. Defining a data structure for that is relatively simple. The two issues you get on top of that-it’s all very well having this data format, but how do we make sure it actually does stay with audio and video? How do we bind them together? We can’t solve that entirely with a new standard, but we intend to say: these are the audio and video standards you should go back and fix. For people who make new equipment or revise old equipment, there needs to be a mechanism that makes sure this label is closely tied to the image or sound itself, making it more difficult for them to get separated.

There are some easier areas. You can already buy cameras today that provide MXF files directly. We need to specify how the new time label gets incorporated into the MXF package right from the outset. If we do that, we provide a lot more robustness in what goes through production and post production so you’re not continually trying to do a virtual clapboard to find out which elements really do live together.

We are still looking at a number of issues, and some of these things are still very much under discussion. There are people in the editing community saying that, while labeling each frame or access unit with a time value is really helpful, there are times in the editing domain where what we really need is a frame count, irrespective of what the time value is. Perhaps this is just an extensible data structure that includes certain fundamental elements, including a defined mechanism for adding your own information to it when you’re in, for example, an editing environment.

Also, we need some unambiguous way of going backward and forward to a 12M timecode, knowing that we’ll throw away some information when we go into the 12M environment, and when we come out we’ll have to flag that we only have this much information because it came out of 12M. Possibly there is an even better way of using those 80 bits through conventional time code equipment to carry different and better data than is in 12M itself.

A lot of these things are still under discussion, and this is where we’re looking to the users to help us satisfy their needs. That’s one of the reasons I’m doing the tutorial session at the SMPTE conference at the end of the month. We’ve had some users involved, but this is a good time, particularly in the Hollywood environment, to expose our thinking to more of them. We are still open to input. If we’re on a wrong track, let us know. This is a time where we need you to start looking at our thought processes and applying them to the way you think your workflow ought to work. Are we doing the right thing? Have we missed something?

Is there anything else production and post-production professionals need to know right now? You mentioned that proprietary solutions could work their way in and gum up the works. Is that a real possibility?

It’s conceivable, but we’ve got a lot of the major players on board. It’s important to socialize this, particularly in Hollywood and the other major post centers, to make sure we’re interacting. If there is somebody else looking at this that we don’t know about and thinking about proprietary solutions, please come talk to us. We think we have good ideas and we’ve got most of the major equipment players on board. It’s to everybody’s benefit to have this done via a standardized solution.

It sounds like the work on synchronization isn’t quite as far along.

We are, I think, over the hill and now coasting down towards something everybody feels comfortable with. We had a pretty big breakthrough in Geneva last week. We’ve got a small group of the most involved eggheads at the moment trying to document all this and make sure everybody’s happy. We want to build some prototypes and check them out, and we want to make sure we start to understand how this works and what its performance will be.

We think we can hold costs down quite a lot lower than they are today by not having a dedicated distribution for synchronizing signals ‘ basically letting it ride on things that have to be there already. We don’t think the world for new installations actually needs the synchronizing precision we used to need for NTSC and PAL composite installations, where we had to time everything to one degree of subcarrier. Every bit of digital equipment has some buffering on its input and probably the same precision requirements don’t apply. We’ve also put a request out to manufacturers in the business saying, “We think these numbers are actually what’s needed. Do you agree?” There are still questions, but I’m very pleased with the progress we’ve made and I think we’re headed toward a converged solution.

What else should people be looking for at the SMPTE conference later this month?

There is actually a very good mix. In many ways I don’t like parallel sessions, but we have so much good content in this conference that parallel sessions were absolutely inevitable. Generally speaking, I think there will be a very obvious split of techies in one session and artists on the other. But there are many gray areas, and much of the stuff in there is of interest to everybody. The session where Lenny Lipton [CTO of Real D and a SMPTE Life Fellow] is comparing 3D using actual stereoscopic acquisition to 3D created artificially by people like In-Three with demonstrations of both-should be absolutely fascinating to the ultimate techie and the pure artist.

Our image-acquisition session has a variety of papers addressing specific issues. We can all talk about great theoretical things, and talking is important to making progress, but there’s a big element about actual real-world problems and how you would solve them. And we’ve started a new technology committee specifically addressing distribution over broadband networks. The idea is to try and standardize all of the elements like compression and DRM, so that content producers can have a package that will work on multiple devices over multiple deliveries. It’s very much a branch-out-into-the-21st-century effort for SMPTE, but there’s a very real need, and multiple interests are trying to come together to produce a standardized solution that should reduce the proliferation of proprietary techniques.

For more information: www.smpte.org