Are SMPTE TC and PAL EBU history?

[dr sound]

Are SMPTE TC and PAL EBU history?

Read this:
http://www.hollywoodreporter.com/hr/...1f275a40ab8291

Interesting!

[georgia]

Sure... the French, the English, the Germans, the Americans, the Aussies, and all the rest are going to agree to a new standard. Then all the manufactures are going to jump right on it and offer all new hardware and software, while all the broadcasters and film distributors are going to completely replace their gear...

... sometime in 2117...


cheers
geo

PS: only kidding... here's hoping they actually come to some sort of reasonable set of standards.

[networker]

What? A world without pulldowns, gearboxing, Smart Sync, oddball references, people who think they're at 24 when they're at 23.98...?

Where's the fun in that?

[philper]

It's interesting to speculate on what this new "frame marking" method might be. Since we got away from systems in post that were actually driven by TC (as opposed to sample rate) TC has become a lot less important anyhow.

Philip Perkins

[Richard Fairbanks]

Good post, Marti! I will not miss SMPTE/EBU code. Death to SMPTE/EBU code.

There are already provisions within recent compression codecs for markers of picture and audio sync, so that realtime picture+sound data leaving one computer can be packetized, sent out of order, and reassembled with the two streams still in sync. This is how your set top cable box can collect the data packets, reassemble them, and picture and sound can emerge in the same relationship as when they left the central server. This is what the box uses when the data is interrupted and you suddenly see the picture and sound out of sync by a couple of seconds. Over a short interval, the set top box time compresses/stretches the audio enough to put it "in sync" again. As often as not, the sound is out of sync anyway because that is how it left the cable company servers. The manufacturers know the problem of audio/video sync starts long before it is sent to the consumer.

It would be good to have a single method to earmark audio and video sync from origination, the shooting stage, always remain present and valid, and not tied to a single compression codec. LTC (linear time code) does that but it was really designed for linear tape recorders. The LTC system fails horribly with newer data storage techniques that easily allow picture data to be formatted to many different image frame rates simultaneously upon demand. We all know how difficult sync problems become when frame rates and LTC data are not managed simultaneously and intelligently. For instance, when you send your NTSC videotape to be converted to PAL, the two tapes may begin at the same timecode number, and program run time may be identical on each, but the actual timecode numbers ("markers") are totally different because the tapes frame rates are different. You will have the same images with different timecode markers, depending on the framerate. Final Cut Pro's marking of 23.976 material as 24 fps during omf export is another example of potential trouble. Being able to reformat image into different frame rates on demand, or re-sample audio to different sample rates, requires a method of synchronization that does not reply on frame rates or sample rate as a realtime clock source. "Markers" tied to image frame rate, like LTC is, and can easily become useless. "Markers" need to be defined by atomic decay or some other method that equates to clock time.

Unfortunately, we will continue to have pullup and pulldown issues, because our new HD standards were built on the old SD standards and still allow for realtime speed shifts during playback, between 60fps and 59.97fps for instance.

Everyone, manufacturers and users, knows a serious problem exists. It is obvious to anyone who watches content, even the most casual viewer. It has been a central discussion point during the last few NAB and AES conventions. Everyone wants a fix, the customers (us!) are willing to pay for universally agreed upon fixes. As usual, large manufacturers will continue to build in proprietary methods to corral their buyers. They want standards, they NEED standards, and yet they will stand in the way until they see there is no longer a profit in it.

While they are at it, they ought to implement a standard for image latency in picture monitors. It COULD be done as part of this new initiative. That is the other half of the problem, and is not currently being addressed. Well, I suppose it is being addressed in a way, because newer display technologies are faster than the first generation or two of plasma and LCD screens. So, latency is less. It is not eliminated. Audio is all handled digitally now, too, which introduces latency. What we see and hear is definied by our speaker and picture display paths. Those both have latency, they affect our sync perceptions, and there are no standards yet, nor talk of standards, to make them the same. Syncheck still has a purpose.

[John McDaniel]

While they are at it, they ought to implement a standard for image latency in picture monitors. It COULD be done as part of this new initiative. That is the other half of the problem, and is not currently being addressed.

Timebase correction in media plant pathways remains a HUGE problem as well. In the process of aligning the timebase of Incoming video (from a wireless camera on the field, a satellite, an image inserter, or a video processor) audio quite often takes a path around the video processing unit without any delay compensation to realign the audio to the video. I FIND THIS EXTREMELY ANNOYING AND IT IS RAMPANT IN THE BROADCAST/CABLE INDUSTRY. Audio leading video is completely UNNATURAL and, being physically impossible in our world, IMHO, unsettling on a sub-conscious level.

A frame's worth of audio delay I can deal with. I just pretend I'm sitting 35 feet away from my TV.

j mcd

[Richard Fairbanks]

If audio and video are timestamped in a way I imagine they could be, realignment COULD and SHOULD be automatic before the image and audio streams enter or leave the broadcast facility. If image and audio are tagged in such as way that a re-sync device knows they belong together, and can calculate how to re-align them time-wise, the streams could be put in sync just before exit. As long as timing tags are applied properly when each data stream is created, the system will work. Any video device that alters the video time sync should change the time data appropriatedly, but should not change the stream identifier. Same is true of audio. Separate video switchers and audio routers should pass the data along, with time stamps modified accordingly, but with stream identifiers intact. Devices that handle audio and video at the same time can be enabled to re-sync them.

We need to agree on a standard, a method, to pass along this "metadata" throughout the production chain. The basic technology is mostly already in place but we need to agree on how the metadata is written and used, which bits mean what.

In some ways, Dolby has set a good example. Their system of metadata is very clever. It fails for two reasons. First, it is complicated and operators are generally too lazy to bother with it. How many people do you know actually make an attempt to set the dialnorm level correctly when they burn DVDs? It is easy to do, but often just set for "-31" because they don't know any better and don't really care to learn. The second lesson, Dolby's metadata is proprietary to Dolby and therefore not widely supported by anyone else. It doesn't apply to audio/image sync problems anyway, but there are lessons to be learned. An effective solution must be free of intellectual rights, which is only possible by mass agreement at a level far above the DUC. Also, it must be handled in a mostly automatic way by the equipment, without relying heavily on the people operating the equipment.

Lots of problems will still occur during live productions, like news broadcasts, where graphic and text insertion causes image delays, and audio sources are mixed together. That is why it is so important to use automatic resynchronizers on each incoming source.

And, it would be possible for monitors and speaker systems to react to timing data as well. I'm not sure it is a good idea to take it that far, but it could allow different picture monitors and audio playback systems to be in sync with each other in a more automatic way.

[JimC]

God created Time.

Only man can screw it up.