intro.JPG
resume.JPG
cv.JPG
now.JPG
recent.JPG
guild.JPG
agents.JPG
awards.JPG
filmog.JPG
cfilmog.JPG
digivid.JPG
hd.JPG
70mm.JPG
gallery.JPG
visitors.JPG
papers.JPG
scripts.JPG
links.JPG

Peter Gray - Director of Photography

director of photography, peter gray, dp, cinematography, dop, cinematographers, lighting cameraman, videographers, dv, high definition, 24p, digital films, HDW-F900, CineAlta, Varicam, AJ-HDC27F, AJ-HDC27H, Viper, 70mm, independent films, lighting directors, filmmakers, filmmaking, HDW-700A

Tri-level Sync Issues On The Set

line.gif - 3.0 K



The use of external Tri-level sync to genlock High Definition camcorders is starting to become more commonplace for drama-style production. Recent High Definition productions have been using these new Ambient Tri-level "Lockit" boxes (ACL 202CT) that deliver timecode in step with a built-in Tri-level sync generator. And subsequently, a similar unit from Denecke was released, their Tri-level Syncbox model SB-T. However, the introduction of Tri-level to the Hi Def world has not been without its concerns, and indeed, very real problems. Enter the "green flash" or "green hickup" problem (more about this below).


What is the reason to send an external sync source to a camcorder? Well, this is only necessary in multi-camera and double-system configurations, so there has to be "two" (or more) of something to consider using this approach i.e. two cameras, a camera and a separate audio recorder (DAT/hard drive/optical drive), and so on. Sending external camera sync is sometimes referred to as "genlocking", so this term will be used interchangeably in this discussion. Traditionally, genlocking is necessary to enable seamless, live switching and mixing of the images output by several video cameras. If the cameras were not genlocked, or fed the same sync source, you risk seeing a glitch, or some similar image instability, right at the moment of switching the image from one camera to another. Cameras in a television studio, or in an outside broadcast unit, are always genlocked for this reason.



What is Tri-level Sync?

The sync reference going to a camera defines when each frame begins to scan, in fact, when each line in each frame begins to scan, as it progressively builds the entire video image. For NTSC analog video, the sync signal consists of a Blanking Pulse (sync pulse + color burst + "back porch") followed by the video image data. This sync information is repeated every scan line.


However, High Definition camcorders can not genlock or reference to a standard NTSC or PAL video sync signal. Rather, it uses an another type of sync called Tri-level sync designed for High Definition systems. It basically works in the same way as analog sync, but it is structured differently. With Tri-level sync, the signal consists of a three-level sync pulse (zero volts (0V) Blank, -0.3 V pulse, +0.3 V pulse) followed by the video image data. Like analog sync, the signal is repeated every scan line as it creates an entire HD video frame. So in the High Definition world, we need to genlock with what is known as Tri-level sync. By comparison, traditional analog video sync works on two levels, so retrospectively it is sometimes referred to as Bi-level sync (although it was never originally referred to in this way).


But there are other reasons to employ genlocking, apart from its more traditional use in live switching multi-camera productions. Genlocking can also be used for a multi-camera show that is edited later, rather than switched live. For example, a production edited in an Avid, or similar non-linear editing system, or even in an older-style linear editing system (tape to tape). This is the specific application I want to discuss in this presentation. In other words, its application in tradition drama production shot on sets or on location, and edited later.


The reason to consider feeding external Tri-level sync includes the following:

(1) To have the same Timecode number stamped on all camera frames, and also on double-system audio, in the exact same moment in time. This helps facilitate smoother, faster, and more efficient post-production work flows. But as will be discussed below, the relationship between Timecode and Tri-level sync is a vital factor in achieving this, and at the same time avoiding the risk of getting periodic "green flashes" or "green hickups". So hence point 2.

(2) Having a fixed relationship between Timecode and Camera Sync (Tri-level sync) eliminates the risk of problems with these seemingly random, periodic "green flashes" or "green hickups".

(3) HD cameras (also crystal-synced film cameras) can start their recording cycles slightly out of step with one another (i.e. some fraction of a frame). This is not a sync issue per se, just a relationship issue between multiple cameras that will be become apparent later in post. It is a small refinement, but the use of Tri-level genlock ensures all camera start scanning the exact same line at the exact some moment in time. They will be in perfect sync and also in perfect step with each other.

(4) Genlocked cameras will switch smoothly and cleanly (no glitches) as you switch between cameras for previewing purposes (also vitally important for traditionally-switched live shows).

The deployment of Tri-level sync is the basis for achieving frame-accurate, identical timecode-number stamping across multiple camcorders. If you just simply jam Timecode you can get up to a one-frame difference between the camcorders in a multi-camera set up. Or in other words, this means that the Timecode numbers might be slightly out of step with each other, by up to one whole frame, in any multi-camera set up. What is the reason for this? It all depends on where the camcorder's frame-building cycle is in relation to any other cameras shooting at the same time. Imagine three HD camecorders and three operators on a set ready for action. They hear the command to roll cameras and they all press their respective record buttons more or less at the same time. A tiny moment later, all three cameras start recording their first line of video. But they are almost certainly not going to be doing this in the exact same instant in time. For example, as Camera "A" starts its recording cycle by scanning line one of a frame, camera "B" might start its recording cycle while camera "A" is in the middle of building this same video frame, and camera "C" might start its recording cycle as camera "A" is right at the end of building this frame of video. So in this case, all three cameras are about half a frame out of step with each other, and camera "A" and "C" are virtually a full frame out of step with each other. This is not a sync issue per se, as this relationship will remain fixed throughout the shot. This problem (in as far as it is a problem) can be overcome by feeding all cameras identical timecode that is referenced, or kept in step with an external Tri-level sync generator. As the genlocked cameras are now recording in perfect step with each other, Timecode stamping will now occur at the exact same moment in time across all cameras, effectively eliminating any random partial-frame offset between cameras. A simple Timecode jamming operation doesn't establish an absolutely precise relationship between the timecode and camcorder sync across several cameras. With simple jamming, there will always be a random offset within a single frame.


When jamming timecode with a Tri-level "Lockit" box, you are jamming the timecode in respect to a reference source of Tri-level sync. In other words, the advancing timecode numbers are timed to run in a precise relationship with the sync stream. This means that as the camcorder begins to built a new frame of video, the timecode advances to the next frame number, at that precise moment in time. As every new frame starts, the next timecode number appears at precisely the same moment. When you jam these new Tri-level "Lockit" boxes in respect to each other, you are not only getting the timecode numbers to roll in perfect step with each other, but you are also effectively getting the Tri-level sync stream in step with each other (or they run closely enough together that this appears to be the case). Even thought there are individual timecode generators in each "Lockit" box, collectively they behave as if there is a single timecode generator feeding all the camcorders. And similarly, even thought there are individual Tri-level sync generators in each "Lockit" box, collectively they behave as if there is a single Tri-level sync generator feeding all the camcorders at the same time. The secret of the "Lockit" box is that the same crystal generates both the Timecode and Tri-level sync simultaneously, so the relationship between them can never drift apart as they are derived from the same source.


The latest generations of the Ambient Lockit box, namely ACL-202CT, and also the Denecke SB-T Tri-level Syncbox, has an output for Tri-level sync. Both the timecode and the Tri-level sync are fed to the Sony HDCAM or Panasonic Varicam using two short linking cables connected to "Timecode In" and "Genlock" respectively. Of course, you can also send Tri-level sync via cables (or fiber optic system) from some sort of master genlock devise. But using "Lockit" boxes is just a more convenient, and perhaps more versatile way, of doing the same thing, cordless-ly or wireless-ly.



Tri-level Sync Formats?

Both the Ambient ACL 202CT "Lockit" box, and the new Denecke SB-T Tri-level Syncbox, generates Tri-level sync in accordance with the SMPTE 274 - 1998 and ITU-R.BT.709-4 international standards for all 1920(H) x 1080(V) formats. Therefore, both these "Lockit" boxes are fully compatible with Sony HDW-F900 camcorders.


Here is the correct dip switch configuration for the Ambient "Lockit" box when shooting with the Sony F900 CineAlta.


For 23.976 timecode and 23.976PsF (Segmented Frame) Tri-level sync in the F900:

Dip switches #1 ON, #2 OFF, #3 ON, #4 ON, #5 ON, #6 OFF, and #7 OFF.

(NOTE: Both the horizontal (red/black) sliding switches between the bank of dip switches and the (yellow) on/off power switch, BOTH need to be switched to the right-hand position, or towards the power switch, for use with all High Definition camcorders. This sets the unit to output Trilevel sync from the second BNC connector labeled "video".)


On the other hand, the Panasonic Varicam is looking for an external Tri-level sync source compliant with SMPTE 296M and compatible with 1280(H) x 720(V) formats. This is the type, or format, of Tri-level sync used by the Varicam family of High Definition camcorders, namely the Panasonic AJ-HDC27V, Panasonic AJ-HDC27V-M1 (upgrade), and the newest Panasonic AJ-HDC27F. The Ambient Tri-level "Lockit" box will work with the Panasonic Varicam, provided you set the dip switches to output the appropriate format of Tri-level sync (i.e. SMPTE 296M) and use the correct timecode base. The correct Tri-level sync format is achieved with dip switch #4 turned OFF (please note: this switch must always be set to the OFF position for all dip-switch configurations with the VARICAM camcorder). Here is the correct dip switch configuration for the Ambient "Lockit" box when shooting with the Panasonic VARICAM.


For 29.97 timecode with 59.94p (Progressive) Tri-level sync in the VARICAM:

Dip switches #1 ON, #2 ON, #3 OFF, #4 OFF, #5 OFF, #6 OFF, and #7 OFF.

(NOTE1: Once again, both the horizontal (red/black) sliding switches between the bank of dip switches and the (yellow) on/off power switch, BOTH need to be switched to the right-hand position, or towards the power switch, for use with all High Definition camcorders. This sets the unit to output Trilevel sync from the second BNC connector labeled "video".)

(NOTE2: If you set dip switch #3 ON, then you will get Drop Frame timecode, but Non-drop timecode is usually preferred, so normally leave dip switch #3 OFF)


It may seem counterintuitive at first, but this is also the correct dip switch setting for 23.976 timecode with 59.94p Tri-level sync i.e. when shooting "24p" with the Varicam (or really 23.976p). I assume the reason is that the camcorder is automatically adding a 2:3 pulldown to the 23.976p to make 29.97p at the recording stage. So the camcorder also wants to see 29.97 timecode, even though it is set to a frame rate of 23.976 frames per second.



What Can Go Wrong?

If there is an interruption to the external sync source, then the camcorder re-locks to its own internal sync system. But because there is no relationship between the internal sync system and the external sync system, this means there is a momentary problem while the camcorder re-establishes, or re-locks, to the new sync source, whether it be internal or external. The problem is made worse by say, an intermittent problem in a faulty cable or connector, that causes the system to flip flop back and forth between internal and external sync (this is perhaps the worse case scenario).


The sort of things that can cause an interruption to the sync feed is, for example, a battery problem with the Ambient Tri-level "Lockit" box or the Denecke SB-T Tri-level Syncbox. Anyone can get a bad batch of batteries sometimes, or batteries that run down more quickly than you anticipate. Or if there is a faulty cable or connector, or a similar problem (or combination of problems) like this. I've also been told that very damp conditions can cause "green flash/hickup" problems (but I have not experience this directly myself). These sort of occurrences are fairly rare on a professional set, but ‘shit happens' sometimes. And the consequences are potentially dire. But I think the real issue is not how to avoid problems ever occurring 100% of the time..... this is unrealistic. The real issue at hand is how do you detect problems if they do occur, and what you can do about them.


In the old analog days, loss of sync caused the images to roll and distort on the screen, as the system tries to re-lock everything back into sync again. However, High Definition systems do things a little differently. During playback, you might see a green flash in the flow of images, or a series of green frames if there is continuing sync problems. I personally call them green hickups, and this terms seems a little more descriptive than green flash. The system masks, or hides, the image it is trying to play back with a green screen, while it tries to decipher and display those images properly. Technically, they are also called "masking" or "concealment" frames. So in other words, the green masking or concealment frame hide the unsalvageable video with a temporary green screen, for as long as the problem continues. A break in the sync stream almost certainly means that the image can not be displayed properly, so all we see on the screen is a green ‘hickup', or series of green ‘hickups'. As soon as it is possible for the system to display the images properly again, normal playback resumes.


The green frames are a result of the camcorder's error correction system. Any pulses coming from the genlock devise that get out of step with the normal sync stream, causes the camera head to get out of sync with the frame information being loaded into the storage buffer. This results in an impaired signal. If the duration of this impairment lasts more than two segments, the playback system does not have enough information to provide a correct signal, so it inserts a green masking or concealment frame.


So lets say the camcorder is part way through building a frame when the sync information is interrupted. The camcorder has to quickly re-establish a new relationship between the information coming from the CCD's (that is momentarily stored in a buffer) with that of the new Tri-level sync source. The scanning rate of one has to get back in step with the other. As soon as it establishes this new (sync) relationship, then the normal recording process resumes. I don't believe the green flashes are recorded as such, but rather, are inserted at the time of playback only. When the playback system stumbles over the break in the sync information and can not reconstruct and display a full frame of image in a normal way, it inserts these green masking or concealment frames instead.


If the break in the sync stream is momentary and very short, then maybe as little as a single green frame is displayed on playback. Although very short, this is still an extremely annoying interruption to normal playback. ‘Green hickups', even just one of them, are unacceptable for a professional production. And in the worst case scenario, you could lose a major part of a day's shooting because it is riddled with mysterious 'green hickups'. It is possible that the problem goes unnoticed at the time of shooting, only to become apparent in the editing room. So perhaps the biggest problem is that you might not know there is a problem at all, until it is too late.


I believe what I've described above is a technical reality, but despite this the whole issue is somewhat controversial. Some people say it is O.K. to just send master Timecode to all the cameras without any relationship to Camera Sync (Tri-level Sync). And they are right in the sense that it works just fine most of the time, but they can be wrong because of these seemingly-random, periodic glitches. And there is a certain amount of luck involved with a "green flash" or "green hickup". It may occur during set up or rehearsal when you are not actually recording, or it may be in a take, or part of a take, that "ends up on the cutting room floor". In that case, they are not actually a problem to anyone.



The Post Side of the Equation:

If you had just one or two flashes to deal with, you might be able to pull off some sort of fix in post, by cutting out the green frames and using a one or two frame dissolve to bridge the gap perhaps. But it seems you can not simply remove the green flashes in post ... it is not that simple because the playback system is stumbling over actual breaks in sync. The problem is worse than just losing those one or two frames of image (the green frames) caused by the momentary loss of camera sync. If that was the only problem, then you could possibly fix it in the post by editing out those damaged or incomplete frames ....... and replacing them with a frame copy of its neighbor. But because there is a break in the actual sync information, then it seems the playback system will always stumble over this break in the sync information. The problem is that you are working either side of an actual break in sync continuity. And in any case, it would be completely impractical to try and repair say, several hours worth of dailies. And even if you did, it would be full of duplicated frames.


I'm told if you look at it more closely in an Avid or similar editing system, you can step forward frame by frame right up to point where the sync was interrupted. Then if you go over this point, and start coming back the other way frame by frame, you can get back to this same problem point and all the images are fine either side of the break. But the bigger problem is there is an offset in the relationship between the first set of images and the second set in terms of sync. In other words, in terms of the integrity of the sync stream itself, things are out of kilter. If you look at the point where the first line of a frame of image begins to scan in the first set of images, it is different to where the second set of images begin to scan its first line. The relationship is different, or offset, in terms of the sync stream. So just by cutting out the damaged frames, you are still left with the jump in the sync stream itself. If you leave this problem in your final edit, then I believe the playback system will always stumble over this damage to the sync stream, and insert those 'green hickups'. In other words, you can not edit out an interruption to the flow of sync information -which, after all, is what the green flash frame is. Remember, there is no actual physical green fame to edit out.



Detecting the Problem:

I don't mind things going wrong on the set ...... it keeps life interesting. But I have a problem with things going wrong if I don't know anything about them i.e. when there is no easy or reliable way to monitor for these events. Especially a momentary event that maybe only lasts as long as a single frame. One could constantly check playback throughout the day, but if you are relying on playback alone, you will have to play back and observe every single frame, in every single take, from every single camera, to be absolutely sure that there are no 'green hickup' loss-of-sync problems. This is not very practical, of course.


But the most alarming thing is that the camera operator or video tech (DIT) gets little or no indication that anything is wrong. You normally see very little on the monitor. Perhaps a small glitch or disturbance in the signal if you are especially attentive.


Apparently, when there is a momentary loss of external Tri-level sync, the operator will see a brief disturbance in the image in the viewfinder (...provided they are looking of course). Normally they would be looking during a take, but they sometimes use these on-board monitors and therefore might not see anything on that monitor that would indicate a sync problem (.....as they are usually fed a HD-SDI signal like the other monitors on the set).


However, if the external sync is lost completely, as in the case of batteries going flat in the "Lockit" box, the image in the viewfinder goes completely crazy (unstable). So there is no doubt that something is wrong, and something has to be done to correct the problem.


There is a servo alarm on the CineAlta if there is a loss of Tri-level sync. The operator will see a flashing LED in the viewfinder, and hear an audible alarm provided they have the volume turned up sufficiently on the alarm system. And in the case of complete loss, or continuous impairment of Tri-level sync, the camcorder will not go into record. The same thing happens if you have the incorrect Tri-level sync format fed to the camcorder, for example trying to feed Panasonic Varicam-style SMPTE 296M Tri-level sync to a Sony CineAlta camcorder, or vise versa. Like the Sony HDCAM, the Panasonic Varicam will also not go into the recording mode if it is not seeing valid Tri-level sync.


Of course, that alarm flash and beep can mean any one of dozens of different problems, so you still have to determine the cause of the alarm activation. As far as I know, there is no indication for an external sync or genlock problem in the "!" IND menu (Maintenance Menu #2) in the Sony CineAlta HDCAM. This is the normal place you would look to identify the source of problems. (By the way, the "EXT" in that menu is for the lens Extender, and not for External sync.) So after an alarm goes off, there is still no easy way to see that it was connected to a sync problem as such.


And I believe there is an "EXT. LOCK" indication appearing in the LCD display on the side of the CineAlta camcorder (in the timecode display window). This presumably tells you that the camcorder is happily receiving an external Tri-level sync stream. I wonder if the indicator flashes if there is a momentary interruption to the external sync feed? If so, it could be useful in testing a suspected faulty cable or connector to see if it had an intermittent problem perhaps? This indication seems good for telling you everything is O.K., but what we really need is something to tell us if something has gone wrong, especially for just a momentary interruption to the Tri-level feed (possibly an event lasting as long as a single frame).



Is It All Worth It?

Maybe we shouldn't be using an external Tri-level sync source for a regular two-camera shoot that will end up in an Avid anyway (i.e. for normal editing, and not a switched show). I must admit, my only reason to use it is to get perfectly matching timecode numbers between multiple camcorders. But if something goes wrong with the Tri-level sync feed, you can potentially suffer very dire consequences. So perhaps the risk is too big in relation to a relatively small gain if all goes well. The net gain after all, is only to get perfectly matching timecode numbers across two, or more, camcorders. This is just a convenience for the editor rather than a necessity. The offset is in a fixed relationship, so it is easy to correct for this in the post by pulling up one set of timecode numbers in relation to the other.


Maybe the slight benefit of using Tri-level sync is not worth the potential disasters if the system fails without anyone being aware of problems. Green hickups abound. If any interruptions to the Tri-level sync feed is not detected and corrected at the time of shooting, the editor may be presented with unsalvageable material in post. I normally recommend not to Genlock cameras unless there is a good reason (this is because there is always a certain level of risk using external genlock). Like I say, all the advantages are for post, as it makes syncing up the audio easier, and the logging easier, etc. I think the risk of Genlock problems is very low in reality, and perhaps especially with the new fiber-optic systems that are becoming more popular(?). Certainly, multi-cameras are really meant to run in Genlock as it makes everything go smoother. In an ideal world, I prefer to Genlock. But I also like to point out the various "pros and cons" before any final decision is made about this.


Bottom line: If genlocking camcorders, very special care needs to be taken to make sure all external sync feeds are 100% clean, and 100% continuous, to avoid possible "green hickup" problems. As mentioned before, the sort of things that can cause an interruption to the sync feed is, for example, a failing battery in the Ambient or Denecke Tri-level "Lockit" box, or a faulty cable or connector, or similar. I'm told very damp conditions can also play havoc with "Lockit" boxes, such as shooting in the rain with a covered camera.



Note: It should also be noted that you can not use REC-RUN timecode, but only continuous running, or time-of-day timecode (F-RUN) with all Tri-level systems described above. You also need a 10 second pre-roll on all camera and audio start ups, as this is needed by online assembly equipment used in post.



Disclaimer: This is very much a work in progress, so please don't take any of this as absolute gospel. It is just my preliminary understanding of what I think is going on with Tri-level sync and related issues. These writings really reflect my evolving understanding of the issues as I try and piece everything together. Of course, I will endeavor to consolidate and refine my understanding as I investigate things further, both practically and theoretically. I guess what I'm really doing here is sharing my developing thoughts and ideas with other colleagues ...... in a sense, I'm thinking and pondering aloud. Any and all feedback is very gratefully accepted. Especially any information that helps to correct outright mistakes in this article, or additional information that helps to expand the scope of the discussion.



Copyright © Peter Gray (16th March, 2003, with later revisions.)



line.gif - 3.0 K

Peter Gray
(near Los Angeles)
P.O. Box 5132
Pine Mountain Club, CA 93222
United States of America
telephone: +1(661) 242-1234

dp@petergray.org

e-mail annimation.gif - 4.20 K

  top.jpg - 1.98 K  
back.jpg - 2.28 K   next.jpg - 2.20 K
  home.jpg - 2.13 K