Locking HD systems for Live and Post


Locking HD systems for Live and Post

you will need a time code reference signal for positional reference and a clocking signal for frame synchronization. You will need to gen-loc the cameras or at least jam sync them… the decks, the switcher, the delay units, the desk (if digital) will need to be gen-locked and receive proper clocking to assure frame accuracy for video and no digital problems in the audio side. Cross jam can also be performed going to the camera as well with the sound recorder being the time code master. This is especially useful if you are running multiple cameras that you want to stay in sync. For HD you will need devices that will generate 23.976 fps. You may need a box for each camera. HD camers like to be Genlocked to Tri-Level Sync video when receiving an external time code source. Tri-Level sync is related to the HD picture and is not a standard NTSC
video sync source. You cannot Genlock a 24P camera with standard NTSC video sync.

as to question 2…. now thats a fun one.. in a LIVE event situation you need a video / audio delay box so that you can delay the leading signal appropriately. And in fact, you may need more than one depending on live systems configuration. You may need to deal with audio delay in milliseconds and/or video delay in frames… if you are working with a live video switcher it can end up a number of frames off…. In an event where you are NOT broadcasting live, fix it in post.

 

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.

cheers

geo