Protocols are the hidden languages by which your VCRs and other editing
hardware communicate via infrared pulses or electronic signals. In a way,
they’re like the chips that control your car’s fuel injection: you’re vaguely
glad that they’re doing their sophisticated thing in there someplace, but
you don’t care to know what that thing is.
Although that may be true about fuel injection, you need to understand
editing protocols in two areas that directly affect your video post production:
their compatibility and accuracy.
What Protocols Do
All editing protocols, from the simplest to the most sophisticated, use
codes to control the operations of at least two VCRs, telling them when
to go into their PLAY/PAUSE, PLAY, RECORD/PAUSE, RECORD, and STOP modes.
By memorizing and then communicating strings of these codes, edit controllers
can do two things:
- Perform edit sequences that would require an octopus to execute manually.
- Perform one edit after another to automatically assemble video programs.
The simplest protocols communicate in only one direction, sending these
commands from the controller to the VCRs. (This flow is indicated by the
red arrows in Figure 1.) More sophisticated systems also communicate information
from the VCRs back to the controller, as the green arrows indicate. This
information includes the place within the program on the tape in the VCR
and sometimes the current mode of the VCR, such as RECORD, RECORD/PAUSE,
More complex systems add the ability to control additional devices, like
a second source deck for A/B roll editing and a digital effects generator
to make transitions between the two. (See Figure 2.) The diagrams show the
edit controllers as stand-alone boxes, but computers are increasingly taking
on their functions.
What can this information and control communication do for you? When it’s
stored in the edit controller’s memory, it could:
- Specify the exact in and out points of a first shot on the A source tape
and a second shot on the B source tape, along with the start point of the
A shot on the record deck’s tape.
- Program a two-second wipe transition on the effects generator that is
receiving video and audio from sources A and B.
- Instruct the edit controller to execute this shot A/wipe/shot B transfer
When it sent that instruction here’s what would happen:
- Using information fed back from the decks, the edit controller presets
the specified distances of the A, B, and record deck tapes ahead of their
- It places both source decks in PLAY/PAUSE and the assembly deck in RECORD/PAUSE.
- It rolls all three decks at once. At the first programmed point, the
record deck starts recording the A source. At the next point, the controller
triggers the effects machine to make the wipe to the B source. At the memorized
end point of the B source shot, the controller throws all decks into PLAY/PAUSE
If you have ever tried to manually synchronize and execute such an A/B
roll transition through a DVE (digital video effects), you can appreciate
the value of automating the process.
That automation is made possible by the hardware control and program information
communicated through the editing protocol.
As mentioned previously, the simplest protocols have the control functions
but not the information feedback. These one-way protocols (including Control-S,
synchro edit and the infrared signals sent by a wireless remote) communicate
only from the controller to the hardware.
At the prosumer level, we get into two-way protocols, including Control-L
(LANC) and Control-M (Panasonic 5-pin). Typically, these protocols show
where you are in a tape program via the control track time display, but
some can use different types of time code (more about that in a moment).
Compatibility is a key issue with edit protocols because some manufacturers
have developed proprietary systems that work only with their own hardware.
So in order to plug a Sony camcorder into a Panasonic VCR and use an edit
protocol, you’ll need an edit controller that supports both of their proprietary
Compatibility is also an issue with systems that use time code, which labels
each and every video frame with a unique address. (As we’ll soon see, time
code is absolutely indispensable to professional caliber editing.) Not counting
digital and oddball analog formats, there are at least three major types:
SMPTE linear, VITC (vertical interval time code) and RCTC (Sony’s Rewritable
Consumer Time Code). As a student of the laws of the immortal Murphy, you
can easily guess that these three time code types are all mutually incompatible!
The bottom line is that you need to know which protocol(s)–and which type
of time code, if any–you want to use, and then ensure that every component
in your edit system speaks that language.
The most important separator of protocol sheep and goats is their accuracy–that
is, how close to the specified frame they actually execute their commands
and how consistently they are able to repeat them.
Why is this important? Because your human eye and brain can detect mismatched
edits to within two frames or sometimes even one. Suppose you show a full
shot of a golf swing and then cut to a closeup of the ball on the tee just
as the number one wood smacks it. It’s easy to pause the transferred full
shot one frame before contact, but if the closeup comes in just two frames
late, you’ll see a hesitation in the swing that gives away the edit. Two
frames early and the action will seem to repeat itself.
In the edit protocol pecking order, time-code-based systems are most accurate,
wired control track systems are so-so, and infrared systems are, well, not
all that hot.
Infrared control is accurate only to maybe five to ten frames, for two
reasons. First, there’s a lag between hitting the button and sending the
pulse. Secondly, a pulsed command itself lasts longer than the 1/30th of
a second devoted to a single video frame.
But before dismissing infrared control, you should know that some manufacturers
have taken sophisticated steps to compensate for the built-in inaccuracy.
JVC, for instance, uses a clever method of calibrating your particular hardware
so that its edit controller will automatically adjust for inaccuracies.
Even so, infrared is a one-way system. Your edit controller never knows
precisely where a tape is in its program, and that compromises its ability
to locate shots accurately. Some infrared editors, however, use a smart
way to fake it; they treat the start point of the first shot you mark as
"0" and then locate every other shot on the tape by its distance
from that first in point.
Note, however, that this works only if all your footage is on a single
tape and you never remove that tape from the deck as long as the edit controller
is using the shot list based on that initial in point. Another accuracy
limitation is the fact that every distance from the first in point is guesstimated
by the edit controller rather than supplied by the VCR, because, of course,
the deck cannot report back to the controller.
The two-way communication provided by protocols such as Control-L and Panasonic
5-pin addresses this deficiency. Now the position of the tape is reported
to the controller. The trouble is that in most cases, it’s the control track
that is identifying that position–the set of signals that keeps your picture
in sync and, incidentally, operates the hour/minute/second numbers on your
VCR’s counter. This limits accuracy in two ways:
- The control track records an accurate time signal only once per
second. The positions of the 30 separate frames within that second must
be eyeballed by the edit controller.
- The one-second pulses have no individual electronic identities
so there’s no way to tell them apart. Push a cassette into the VCR and the
counter resets to zero no matter where you are in the tape program. So here
again, you can work with only one cassette per VCR and never remove it from
the deck. There are some work-arounds that address this limitation, but
none is entirely satisfactory.
Even with these limitations, a good two-way edit protocol using control-track
shot identification can increase your average accuracy to plus or minus
two to six frames, depending on the mechanical quality of your equipment.
But for single-frame precision, you need time code. If your hardware can
read and write it, you can assign a unique address to every single frame
of your footage. Now your edit protocol can create frame-accurate edit decision
lists (EDLs) and your automated program assemblies will be perfect every
IF–and it’s an all-caps if–your hardware is sufficiently accurate and
consistent to perfectly execute those perfect instructions.
But that’s a topic for another day.