Tri-level Sync and Time Code

Greetings:

In a separate post, I lambasted the use of non-wired free running external time-code/sync generators on multiple camera HD shoots as a useless practice.

In so doing, I neglected to address the specific technical question the writer seems to be asking, which is: "Aren't time code and sync married together? If you feed time code, doesn't it necessarily follow that you must feed sync?" A VERY good question, one I've been asking people for years, and I've never fully gotten to the bottom of.

The answer seems to be :

In theory, yes: Time code and sync are married; especially for blue screen/hi-con effects shoots.

In practice for most shoots : Many crews are slaving time code, but not sync ( or "Genlock").

I was adamant for many years on running genlock (hard wire) to any camera I ran time code (hard wire) to, until I started working with network news magazine shows that had long ago abandoned the practice, shoot 5 days a week this way, and never have problems. (They'd say: "Dude. They did it that way for 'The Ed Sullivan Show'. This is the 1990's. Get with the program!")

As near as I can surmise, with the advent of component video, the color framing issues that were so critical with NTSC were not mission critical with the new equipment, and the editors had learned "workarounds". I also suspect that non-video oriented sound people were botching the genlock (locking to a B&W camera monitor output) and any video engineer will tell you that bad genlock is much worse than no genlock at all.

I suspect that for blue-screen/hi-con/ultimatee special effects work, where frame accuracy is hyper-critical, because you have to simul-roll four or six or more elements it is still "mission critical" to run sync ("genlock") along with time code. I refer here to actual "hard wires" not free-running devices like the "Clockit".

Lew Comenetz

Video Engineer

So Glenn Berkovitz, a good C.A.S. Mixer posts the note below on RAMPS, the rec.arts.movies.production.sound list on usenet. RAMPS is the equivalent of CML, a comparison I donâ€™t make lightly. Glenn said it would be OK to post his note on CML so we can all get to the bottom of this and help move things along.

Glenn writes :

Something I've noticed, on the last three HD projects that I've mixed sound for (a 4 week feature, a three week pilot, and a three day special): on all of these shoots, using Sony/Panavision HD-F900 cameras (#?), the D.I.T. on each job was quite definite that he had been instructed by Panavision (or, through his own experience) NOT to use the HD tri-level sync provided by the Ambient Clockit timecode/sync generators that velcro to each camera.

Other than not using this valuable (I thought essential) aspect of the technology, all our sync-ing methods were to my usual liking: I use a GR-1 as master clock (29.97 NDF) at my sound cart, and feed my PD-4 (or Deva); I jam the Clockit for each camera, set to 23.976 (tri-level), and that's all my involvement with the camera.

What really bothers me is the explicit instruction to NOT use what I thought was a vital part of feeding timecode to a camera - if there's no proper synchronization of the time codeâ€™s leading frame to the video leading frame, I believe there can be drift (or, lack of easy sync). But apparently, due to the "green flash" anomaly, attributed to bad sync into the camera, Panavision and DITs are now ignoring this beautiful feature of Ambient and Denecke's boxes, and I might as well feed 23.98 timecode from a modified generator and toss out the concept of timecode and sync being essential components of one another. It seems like an overly cautious, and under-informed, policy

Some other folks say itâ€™s the lack of tri-level sync that causes the green flashed during TC flywheeling (slip of TC to frame sync). But what do I know? Nothing. However, I figure the folks here would have some thoughts.

I donâ€™t have any interest in point fingers. Just want to figure out whatâ€™s right and help spread the word.

Well?

Jim Feeley
Documentary producer, occasional mixer
Near San Francisco, CA USA

I had intended to stay out of this discussion but now feel the need to make just a couple of comments :

1) The relationship between sync and timecode IS critical. If recording TC on a VTR directly, without regenerating or jamming the code, the phase of the TC and phase of the input video must match within plus or minus 1/2 H. If regenerating (or jam syncing) TC, which is what we do on a F900 and similar VTRâ€™s, the video vertical phase and the TC vertical phase must never drift through the 180 degree ambiguity point.

What does this mean?

All cameras and time code generators have an internal oscillator (clock). When they are free running (no common genlock or reference signal), these internal oscillators all run at a slightly different frequency. Depending on luck of the oscillator draw, you can have a situation where the camera vertical phase, with reference to the vertical phase of the external timecode being sent it, will drift to the point where they pass through being 180 degrees out of phase with each other. When that happens, the regenerated timecode will jump either one frame forward or one frame backward, depending on the relative direction of the drift. This happens because regenerating or jam sync will always maintain a proper TC to video phase relationship regardless of the relative phases of the inputs.

Editors generally don't like it when there is a one frame jump, but there is an even bigger problem. When doing NTSC downconverts, we must do a 3:2 pull down. The cadence of this pull down sequence is usually determined from the TC. If the time code jumps forward or backward one number in midtake, the downconverter will have to re-establish the cadence and this causes extended video break up at that point.

2) What the Ambient Clockits (202T) and the Deneke equivalents do is generate TC and genlock (trisync or bisync, as appropriate) from an extremely stable internal oscillator. By using one of these on each camera
(and ideally to feed the sound mixer as well -- 29.97), and initially jam syncing them to each other, you insure that not only will the TC be the same and in the same phase at all devices, but that the TC and video vertical phase is correct and will not drift relative to each other. Thus, you MUST connect the genlock from the box to the camera otherwise this relationship is not insured or maintained.

How much drift are we talking about? The clockits and the like generally hold to about 1 frame a day without rejamming. However, I've seen cameras that would drift as much as 10 frames in three hours with respect to each other when running internally... You do the math.

Tom Tcimpidis

Tom Tcimpidis wrote :

>1) The relationship between sync and timecode IS critical. If recording >TC on a VTR directly, without regenerating or jamming the code...

Tom knows this stuff way better than I do - and I think its established that several methods can work as long as you know where the problems can occur.

Also, there are instances where you can put the TC onto the audio channel - via clockits or Denecke boxes, and keep it 29.97 native. Ext sync usually not required. Camera use its own unbroken 24fps Rec/Run TC - for some reason some NLE's cannot cope with simply ascending TC, but require it unbroken as well - and this is one advantage of Master TC on audio Ch. On one shoot the Asst Editor had a plugin or a script written that synced the dailies automatically.

2nd, you can rejam the TC slate (or keep a clockit/denecke permanently wired and rejam that every few hours). You'll always have precise visual TC sync as a backup. Don't forget there's that little LED decimal point that tells you what field you're on. The camera and slate may be out-of-phase by a fraction of that frame, but still in-sync. Re-jamming prevents drift. And while the TC roulette may find you 180 degrees out-of-phase on rare occasions - we've synced sound with clapper for 70 years, getting it within 0.5 fps is good enough for me and honestly the only reminders I've heard back from post is "keep shooting all that great coverage, but remind the guys to pre-roll for 8+ sec." which I prefer to the 7am "neg report" on how many green hits you had yesterday.

All I can say is I've never had a problem this way - so why not.

Disclaimer: this is one of many ways of doing it for "single camera style" shoots using more than one camera. Not multicam live events or 24fps monitors or blue-screen shoots with hi-con mattes, etc. Use of "0.5 fps" above was arbitrary as a worst case scenario.

But it is true, once you start putting TC onto the VITC you do have to at least CONSIDER Tri-levelling as well. And then I usually recommend not to and let the rest of the gang duke it out.

2 years ago there was clearly not enough knowledge base on this issue - and even now I'm not sure how complete our data is. I've been told green hits were due to the AD's or my walkie cueing - even though they were not used during takes, or Nextel phones, gas stations, or what have you. The camera house blaming the tape stock. The DIT disagreeing. New bodies and clockits solved nothing. All the while ignoring the tri-level bnc culprit for another couple days - until it was obvious that no Nextels solved nothing and my 1st AC shoots radio test w/o problems. So finally DIT troubleshoots cables.

Then further upheaval about my method of no ext sync - the DIT sends email to the AP saying it may screw up all the footage, then renting an f500 deck to check the dailies and everything turning out fine. Fortunately I had the trust of the Producers and all I wanted is to let us get back to shooting, and guarantee no more green hits - which we accomplished after a week of the DIT's lack of leadership on the issue (again, limited knowledge-base at that time - it wasn't really his fault other than trying to blame everything else in sight).

I wonder if we'll eventually see RAM buffers that "frame shakes" the timing to make a decent, interpolated fix to a sync glitch, but still give an error message. Green hits just don't cut it - I'd rather get error lights to know the gear's masking a problem that might need to be addressed.

Mark Doering-Powell
LA based DP

All this discussion about tri-level sync, time-code, syncing, etc. makes me wonder,

Just how accurate are the internal clocks on broadcast cameras (F900's, etc.).

Is there a measurement for how accurate a clock is (ppm??)? And also if these cameras go out of phase with each other, how come we never see problems with lighting, flickering, etc. as things go in and out of phase?

And are these cameraclocks "accurate" to themselves (they're running at an accurate consistent speed), but just out of sync with each other, or is the problem that they are varying in their speed ever so slightly?

I remember seeing in the Aaton LTR manual that the motor was good for +/- 1/4 of a frame over 10 minutes. Or the Arri SR3 is accurate to .001fps. From the talk about all this drifting around, it seems as though these HD cameras and SD cameras from Sony/Panasonic aren't as accurate as the crystal motors in film cameras, is that true?

Thanks,

Jason Rodriguez
Post Production Artist
Virginia Beach, VA

> From the talk about all this drifting around, it seems as though these >HD cameras and SD cameras from Sony/Panasonic aren't as accurate >as the crystal motors in film cameras, is that true?

I'd like to know if time code reader/generators share a similar crystal clock circuit or if they get their synch from a phase locked loop microprocessor. I've never had to tear apart a TC reader/generator so I never knew for sure and I used to assume that a crystal was involved somehow, but I've learned that old slogan about assume making an "ass out of u and me". Isn't a PLL supposedly immune from inconsistencies like this by the nature of its design?

And isn't the "clock" on most cameras derived from a PLL somehow, at least on MODERN cameras anyway?

Jeffery Haas
freelance shooter and editor
Dallas

Jeffery J. Haas wrote :

>And isn't the "clock" on most cameras derived from a PLL somehow, at >least on MODERN cameras anyway?

I'm not quite sure I understand your question but time code generators in cameras are locked to the camera sync generator. A PLL (Phase-Locked Loop) implies the locking of an oscillator to another source and, as you suggest, would not drift with respect to a stable source. We are not talking about internal time code drifting with respect to internal camera sync, or even external sync when the camera is "genlocked". The issue is the drift of an independent time code generator (or video source) with respect to another independent source. Because these devices have finite accuracy, they will eventually drift apart if not locked together. The difference in actual frequencies will determine how fast.

This discussion began with a question by Lew about the practice of feeding time code to cameras without feeding a corresponding genlock signal. Evidently many people recommend this practice, even though manufacturers do not and technical rigor seems to indicate that it will eventually cause problems unless you are very lucky. If the sources are relatively stable, there will be few times when the code actually crosses a frame boundary and, unless you are recording continually, the odds of that happening in a take are not that high. On the other hand, code or sync glitches caused by bad cables are much more likely to cause visible glitches in recordings, often causing hits when cameras are moved.

Another answer may be found in the way that camera time code generators lock to external sources. Cameras like the F900, which continuously slave to incoming code can have problems when code is fed to the camera without locked sync. Sony makes this clear in the camera operations manual. Others which jam only at the beginning of recording may work fine without sync. Finally, your satisfaction depends on the level of accuracy that you expect from the system that you design, and your experience with various system failures.

Charles R. (C.R.) Caillouet, Jr.

Vision Unlimited/LA
HD production technical support since 1987
...searching for the right tool for the job...

>Because these devices have finite accuracy, they will eventually drift >apart if not locked together. The difference in actual frequencies will >determine how fast.

Does this mean (or are you saying) that a camera doesn't necessarily always stay at 29.97 or 23.976, etc., but "floats" a little bit, meaning at any given point in time it might be at 29.99 or 29.96 or 23.974, or basically the frame rate could be +/- .01 or .005 depending on the camera?

I mean for cameras to be "synced" together and then float out of sync means that they can't all be running at a true 29.97, 23.976, etc., I mean there must be some sort of "float" in that frame rate or in the clocks of the cameras for this to be happening, no?

BTW, a friend told me that the clock on the Betacams is only accurate to .01fps, while film cameras like the Arri are to .001fps. That didn't seem right to me, so I'm just putting that out here to double-check.

Jason Rodriguez
Post Production Artist
Virginia Beach, VA

> BTW, a friend told me that the clock on the Betacams is only accurate to >.01fps, while film cameras like the Arri are to .001fps. That didn't seem >right to me, so I'm just putting that out here to double-check.

I think that addresses my question too....which is :

If a motion picture camera like the ones mentioned is so damn accurate why can't they do the same for a TC reader/generator being used on a high end video camera. I was aware of the issues that Charles Caillouet mentioned but what I don't understand is why the makers of outboard TC devices aren't a little more discriminating.

These "black boxes" are expensive to buy or rent, a slight pain to use and are, as with any outboard gear, just another link in the chain that can go bad. I know that crystal technology has to have made advances in the last fifty or sixty years, because I remember when older crystal oscillators had "crystal ovens" to regulate the temperature of the crystal in order to maintain stability.

Not complaining...just curious....maybe someone could come up with a "bluetooth" solution to "slave" all the outboard gens to a master? Or is that another "dumb idea"?

Jeffery Haas
freelance shooter and editor
Dallas, Texas

>why can't they do the same for a TC reader/generator being used on a >high end video camera.

Didn't we just say that the TC reader/gen is also locked into the main time source (main clock) on the camera itself? So if the timecode is drifting, isn't the camera speed (CCD clock, tape clock, etc.) itself drifting? I'm thinking everything in the camera should be locked to a single source, right?

BTW, that .01fps accuracy seems a bit dubious to me, if anything it's probably more like +/- .005fps over the course of a recording period (average framerate over that period would be in that ballpark, which still isn't good-or that accurate-if true)

Jason Rodriguez
Post Production Artist
Virginia Beach, VA

The FCC-required frequency accuracy for NTSC is plus or minus 10 Hz. at 3.58 MHz. That is roughly 3 parts per million accuracy. If we assume that camera manufacturers attempt to achieve that in their designs (I have no way to confirm or deny this hypothesis), that means that the speed accuracy of a given camera (at 24fps) is plus or minus .000072 fps. That equates to 6.2 frames a day drift or a maximum of 12.4 fames a day difference for two cameras at the opposite ends of the tolerance. This is a much tighter tolerance than the typical film camera but is still not good enough for the purposes and reasons that were being discussed, assuming that such a tight tolerance could even be held (and my empirical experience has shown that such is often NOT the case - the worst I have seen is about 30ppm from a Panasonic Varicam). A clockit, as a case in point, has a VERIFIED real-world tolerance about 15 times tighter than the ideal FFC specification...

Tom Tcimpidis

>Just how accurate are the internal clocks...

Using Jason's numbers, and if I understand the specs correctly...the Arri SR3 would be +/- one part per 24,000; the Aaton motor would be good for +/- one part per 57,600; the SMPTE spec for HD SDI is +/- one part per 100,000; The FCC spec for NTSC, as Tom indicated, is about +/- one part in 350,000; the Ambient Lockit claim is "up to" +/- one part per 5,000,000.

All will drift. The questions are "How fast?" and "How far is too far out?"

If you are shooting short segments and you jam before each take, you can stand quite a bit of drift. Likewise if there are no hard clues in the frame for sync. If you are shooting a concert which lasts for an hour at 24 fps, the show would contain 86,400 frames, so one part in 57,600 would put you within one and one-half frames, probably not a show stopper.

If you were expecting code to be consistent over a day so that you could correlate views of the same event from distant points, you would need to maintain one part in 2,000,000 or better to be within one frame.

In order to maintain two cameras within tolerances close enough to dissolve between them for the duration of a live hour-long show would require an accuracy of greater than one part in more than 100,000,000,000. That's why we use external sync on live shoots. One alternative is to use a frame synchronizer but then you run the risk of dropping or adding a video frame at an inopportune time, and you introduce an indeterminate delay.

So, once again, the answer is "It depends on what you are doing and what you are willing to accept."

Charles R. (C.R.) Caillouet, Jr.
Vision Unlimited/LA

Charles - there's some funny math going on in your post.

If there are 86,000 frames per hour then the accuracy required to prevent drift between two cameras running for an hour would be one part in 172,000 which as you'll note is within your stated accuracy for NTSC.

I believe that the actual spec for NTSC is what you noted for HD-SDI since this spec is derived from the NTSC standard. This means that over an hour the maximum drift in TIME CODE between the two cameras would be a frame. There would be no difference in the image so you could dissolve as often as you like. There could be a difference in the time code on the side of the cameras but in a non-genlocked situation, the recorder is running it's own time code and doesn't have to match the camera.

This is all pretty much how many angels fit on the head of a pin territory.

Robert Goodman
Author/Photographer
Philadelphia, PA

Charles R. (C.R.) Caillouet, Jr. writes :

>you would need to maintain one part in 2,000,000 or better to be within >one frame.

GPS

Tim Sassoon
SFD Vfx & creative post
Santa Monica, CA