|adamwilt.com > Video Tidbits||copyright © 1998-2004 Adam J. Wilt|
|Tips and tricks in video production||search|
[Last updated 2004.02.05]
Recovering from DV mistracking errors: Occasionally you'll get a tape that won't play back properly, showing blocking or checkerboarding in bands across the picture and/or towards one edge of the picture. I've now seen several tapes that won't play back properly in this way, including one that wouldn't play back correctly in either the Canon XL1 that recorded it nor in a DVCPRO VTR. I've found that most Sony gear will do a pretty good job where other manufacturers have a hard time with such tapes. However, when the really badly mistracked stuff won't play back properly in just any old Sony machine, you can often recover the images in a VTR with Dynamic Motion Control capabilities such as the DSR-1600, DSR-1800, or DSR-2000. These will work with any DV25 tape: DV, DVCAM, or D-7. The DSR-2000 will even recover mistracked LP DV tapes some of the time.
DVCAM tapes can be used in DV recorders and vice versa. I used DVCAM tapes in my DHR-1000 when I couldn't get DV tapes longer than 60 minutes in my neck of the woods. To suss out what tape you need, take the DVCAM running time and multiply by 1.5 (since DV uses a 10 micron track pitch to DVCAM's 15 microns). For example, a PDV-94ME runs for about 141 minutes when recording DV. Likewise, I've run many a DV tape through a DVCAM camcorder with no problems.
Recording DV unlocked audio via FireWire with the DSR-30 DVCAM VTR : Press and hold down RECORD and PAUSE while turning on the power. The deck will emit a sustained beep, at which point you can release the buttons. It will now accept unlocked audio. It'll record 15-micron DVCAM still, but the audio will be unlocked. This trick is also supposed to work with the DSR-200 camcorder. Note: the DSR-11, 20, 40, and other will record unlocked audio without needing this trick. Late-model DSR-30s are also supposed to accept "NS AUDIO" (nonstandard, i.e., unlocked) without too many conniptions.
Color bars on the DCR-VX1000 and DSR-200: Press and hold PHOTO and the START/STOP red button while turning the camera section on. You'll get full-field bars which you can record, along with any incoming microphone audio. You'll have to turn the camera off to get rid of them. More recent cameras, like the VX2000 and DSR-PD150, have colorbars selectable in the menu.
Color bars on the Canon XL-1: Turn on the camera to the fully auto mode (green square). Then press both the shutter speed buttons simultaneously for a few seconds, and full-field bars will appear. Pressing both buttons again for another few seconds turns them off (a definite improvement over the Sony).
Playing DV or DVCAM on DVCPRO VTRs: First, make sure your machine is up-to-date: VTRs made before June 1997 need an eprom upgrade to play DVCAM. Check the serial number: it's of the form MYxxxxxxx, where M is a month letter, A-L, and Y is the last digit in the year. F7xxxxxxx means the machine was built in June 1997, and it's OK. H6xxxxxxx would mean the machine was born in August of 1996 and the EPROM upgrade is required. Second — and this is very important — use the setup menus to specify DV or DVCAM before you insert the tape! The playback mode “locks in” when the tape is inserted, so if you set DV or DVCAM mode after loading the tape playback will still be attempted as if the tape were a DVCPRO tape, and you'll get really crappy results.
Line inputs on the VX1000 (or other consumer cams)? You can fake it: first you'll need a 3.5mm dual-mono-to-single-stereo Y Adapter, Radio Shack Cat. No. 274-375B; this'll give you right and left channel mic inputs on separate mono jacks. Use an Attenuating Audio Cable with an RCA plug on the line end and a 3.5mm miniplug on the mic side: Radio Shack Cat. No. 42-2461A. Sony also makes a stereo pair version of this; if you just need one, peel the two cables apart. You can now jack into line-level audio sources. With a bit of luck, you can even plug a line source into one side, and a mono mic into the other — and the levels might even match up... If you follow this route, be sure to gaffer tape the cables out of the way so that they don't get pulled or wiggled during the shoot, and avoid touching or moving the $%#@&! delicate miniplugs. Also, only use battery power when recording via these jacks lest any residual power-supply ripple or ground loops cause intolerable AC hum problems.
Using monophonic mics on cameras like the VX1000: the mic input on the VX1000 and most similar cameras is a standard 3.5mm stereo minijack. If you plug in a mono mic, you'll only get one channel of audio. Use a mono-to-stereo adapter available from Radio Shack to fix this: part # 274-374. Or, use a 3.5mm dual-mono-to-single-stereo Y Adapter, Radio Shack Cat. No. 274-375B to give you separate mono right and left channel inputs for two mics.
Line/Mic adapter boxes and cables: if you don't want to mix 'n' match cables as described above, Beachtek, Sign Video, and Studio1 offer very nice adapter boxes allowing switchable line/mic inputs and the use of XLR cables with many of the small consumer cameras. Equipment Emporium and Calrad both carry premade XLR-mini adapter cables of various sorts, many designed specifically for solving these sorts of connection problems.
Those Canon IF lenses on the DSR-500WS and possibly the DSR-300 are so pleasant to use and make such nice pix — if you can avoid bumping the %$#@* macro button! The 18x on the DSR-500, at least, has a large and easily-pressed macro ring lock button located on the left side of the lens. Older Canon lenses had a lock button you had to pull up on to move the macro ring; it was virtually impossible to bump the lens into macro mode accidentally. The new lenses have a push-to-unlock button with such a light touch that accidental macro shots are almost impossible to avoid. On two occasions now I've managed to just brush against it while groping for other lens controls or when moving the tripod to a new setup, bumping the button and turning the ring just enough to screw up focus but not enough to be readily visible in the finder. I suggest gaffer-taping the macro ring in place so it doesn't get moved accidentally.
Mixing different brands of tape: In DV's early days, Sony and Panasonic tapes used different lubricants, and if you used one brand a lot and then switched to the other, incompatibilities between the lubricants (which get deposited on heads and tape guides) could cause VTRs to jam up or the heads to clog, sometimes permanently. Supposedly the lubricants were made compatible starting in 1997, but I'm still hearing horror stories about these problems in the summer of 2002.
This is not a DV/DVCAM vs. DVCPRO problem; while many of the people reporting the jams are inserting the occasional DV tape into a DVCPRO transport, many others are seeing the problem in DV and DVCAM equipment, which (high-end DVCAM gear aside) can't play back DVCPRO to begin with. It also happens when other brands of tape are intermingled, not just Sony and Panasonic.
Anecdotal evidence would seem to indicate that the biggest problems occur when one brand of tape is used exclusively for a long time, and then the other brand's tape is used: instant mess! If one switches back and forth between the different tape brands frequently, say, switching between Sony and Panasonic every three or four tapes, the problems don't seem to appear.
Frequent switching apparently prevents a critical mass of one lubricant building up in the transport; switching tapes may clean off accumulations of gunk before they get heavy enough to cause problems. Whether this is really a solution, or if frequent switching only leads to a longer-term buildup of cross-contamination pollution on the tapes themselves, is unknown.
I run about 50% Panasonic DV tapes in my gear, with the remainder being a mix of Sony DV or DVCAM, JVC, and the occasional Fuji. I've never had a problem. It's rare that I run more than four hours on one brand before using the other brand of tape, so that may be a good starting place as to what a safe interchange frequency may be.
Thus there appear to be two general approaches to this problem:
Problems with tape interchange of this sort seem to be reduced by using a tape cleaner in between the different tapes. Especially in this instance, do not rewind and reuse the cleaning tapes; you'll just be mixing old gunk with new if you do so. Also, do not wait until you've run one pass on the new brand tape and seen blockies or dropouts: using the cleaning tape at this point may only polish the gunks firmly into the heads. Clean the heads before inserting the new tape.
Your results may vary: and if you've had any positive or negative experiences of this sort, I'd like to hear your story...
FireWire Frustrations: FireWire 400 (FW400) has more than enough bandwidth even for dual-stream DV, yet plenty of problems can occur when running FireWire disks and FireWire cameras on the same bus. There are a few possible reasons for this:
Many cameras / decks / converter boxes have used a very minimalist implementation of the 1394a spec, barely sufficient to find a compatible A/VC host on the bus and talk to it. Hence the oft-observed "baby duckling syndrome": hook up two FireWire decks to a Mac or PC, turn 'em on, and the first thing each one sees is mommy. Sometimes the decks talk to each other, ignoring the computer, sometimes one talks to the computer and the other is ignored, etc.
FireWire bridge chips in disk housings have comparable pathologies. Folks report that some drives work well on the end of a daisy chain but not in the middle of a daisy-chain, for example.
All these same caveats also apply when using a FW800 bus, of course.
I routinely play/record using a 7200rpm IBM DeskStar in a three-year-old ADS Pyro case using the Oxford 900 chipset with a Sony DSR-11, DHR-1000, or PD150 daisy-chained off it on an 800 MHz TiBook. I'm just lucky in that all this stuff happens to play nicely together. Your mileage may vary, depending on what equipment you're using.
Also note that using a common, low-cost FireWire hub will not help solve these sorts of problems. The best workaround I know of is to segregate disks on one bus, and your DV device on another. If you have a desktop or tower computer, you can add a PCI FireWire card; if you have a laptop with a CardBus slot, adding a CardBus FireWire adapter is the way to go.
DPS Spark problems: Vynny Ward compiled an excellent help page which is now posted here.
NEVER stuff a Betacam tape into a UVW-series VTR without checking to see if there's already a tape inserted. The tape will go in just about all the way on top of the existing tape; it'll then jam in place. UVWs do nothing to prevent this! Fortunately, unless you've really rammed it in enthusiastically, you can usually pry it out, and usually without any permanent damage occurring...
Phil Dippel at Technisphere adds: “Anyone who ships UVW-1800s should always make sure that they last place a small cassette in the well. If you ship after a large cassette was inserted the posts can bend after the machine receives a shock. This will insure that the machine can no longer accept small cassettes until a technician repairs the unit.” This caveat probably applies to all UVW-series machines.
I spent almost four years writing software for the Abekas A72 in the early ’90's; I learned a lot about what works and what doesn't work when putting text on a video screen.
Doing good CG in interlaced video is trickier than you might think. Doing it right in compressed interlaced video (such as DV) is even harder. With interlace, you can have problems of line twitter on static or moving text, as well as roll-induced "crawlies" and distortions. With compression, you add problems of codec pathologies. And there are always pitfalls associated with colors and bandwidth.
Line twitter occurs when you have fine, single-line detail that appears in one field but not in the other. The detail so rendered will flicker at the frame rate, while the rest of the image updates at the field rate. The frame rate (29.97 Hz in 525-line NTSC; 25 Hz in 625-line PAL) is slow enough that your eye notices the flicker, and it's very annoying.
First, make sure that the fonts you use don't have fine, single-line horizontal strokes that will show up as line twitter. Look at heavier fonts in the same family: instead of light or roman, look at bold, extrabold, or black variants. But bear in mind that instead of using Coronet or Script Light, you might have to switch to Helvetica or Times Bold. Often I find that the delicate typefaces I prefer in print work just won't translate properly to video, and I have to find something else instead.
If you're dead-set on using a fine, light typeface, try building a font that thickens up the strokes: use outline, soften, glow, or extrusion (solid drop shadow) effects in a similar color or brightness. Sometimes a soft drop shadow in a similar color with a minimal offset can be used — even Premiere 4.2's limited text capabilities will give you that much!
The problem with interlace and rolls is that as the text moves up the screen, its position with respect to each field's line structure can either change, or stay the same. If it stays the same, your text will look as good moving as it does when it's still. If it changes, the text will lose resolution and may flicker, distort, and crawl around as it rolls.
Imagine characters in a screen font with a height of 10 lines. When placed on a page at its starting position, the even scanlines in the character all fall on the even video field, while the odd scanlines fall on the odd field. As the text sits there, the even fields show lines 2, 4, 6, 8, and 10 in the text, while the odd fields show lines 1, 3, 5, 7, and 9. All ten scanlines in the text are seen over the course of any two fields.
Now start a roll. Any decent CG updates the roll on a field basis; after one field is displayed, the text is moved up a certain amount for the next field, up the same amount for the next field, and so on.
Let's say that the director wants a nice, slow roll, to kill some time. You've selected 60 lines/second (CGs that allow you to set the roll rate usually use scanlines per second as the measure, and in NTSC-land the 59.94 Hz field rate is rounded to 60 Hz to keep operators from getting bogged down in fractional math. If you're in PAL-land, assume you're rolling at 50 lines/second for this example), and pushed the "go" key on the CG.
Now in the first even field, character scanlines 2, 4, 6, 8, and 10 are shown. Next the text is moved up one scanline because at a nominal field rate of 60 Hz, one scanline per field results in 60 lines per second. So when the odd field is displayed, the text, being up one line from its even-field position, has lines 2, 4, 6, 8, and 10 displayed again — and lines 1, 3, 5, 7, and 9 don't get put onscreen! The next vertical interval comes along, and the text is moved up one line again, so that the even scanlines once again appear in the even field. The next vertical interval arrives, and up goes the text again — one line! — so that the next odd field, like all the even and odd fields before it, shows the even scanlines of the text. The odd scanlines in the text never appear onscreen!
The result is half-vertical-resolution text that looks awful. Thin horizontal strokes will either appear about twice as thick as they should, or twice as thin, depending on your luck (sometimes you get the evens, sometimes the odd scanlines, depending on the CG you're using, the initial position of the text, and the field timing when you press the "go" key).
Now go back and double the roll speed, to 120 lines/second (or 100 lines/second if using a 625/50 CG). Now, the first even field shows the even scanlines. Come the vertical interval, the text is moved up two lines (two lines per field times 60 fields per second gives 120 lines per second); the relative positioning of the text with respect to the field structure remains the same, since the even scanlines are moved up two lines to the next higher even scanline, while the odds are moved up to the next higher odd line. When the odd field is displayed, the odd scanlines in the text are shown, just as they should be! The full vertical resolution of the text remains.
You may have noticed a pattern here. When the roll rate (in lines/second) was the same as the field rate (in fields/second), the roll looked awful. When the roll rate was twice the field rate, things looked fine. As it turns out, this relationship holds for all integer multiples: roll rates that are odd multiples of the field rate look awful. Even multiples look great. Thus for 525/59.94 (or 525/60, more or less) video, good roll rates are 120, 240, 360, and the like. In 625/50, the good ones are 100, 200, 300, 400, and so on.
Unfortunately, in 525/59.94 the only two decent rates that are slow enough to be read are 120 and 240 (and the latter only on a good day!). 625/50 video is better — not only are the roll rates about 20% slower, there are almost 20% more active scanlines in a frame, so in 625 you can roll at 100, 200, and 300 lines/second without straining any eyeballs.
What about roll rates that aren't integer multiples of the field rate? As you might guess, as the text moves, its positional relationship to the field structure no longer follows an integral structure, but changes on a field-by-field basis. This leads to two things:
What real CGs do to avoid this is to offer only the “good” rates by default; extra work is required to set arbitrary roll rates. When you select timed rolls (the total time is set, rather than the speed), better CGs will fiddle things to wind up with a good rate. Some may just pick the rate that comes closest to meeting the desired time; some Chyrons run part of the roll at one rate, then “shift gears” to finish at a different rate to get the desired total duration; the A72 (and probably the Texus) “adaptively spaces” the text in the roll, stretching or compressing the vertical line spacing to allow a good roll rate to be used and still meet the time target.
What crummy CGs offer in the way of speed control is none at all. For example in Premiere 5.0, where they've finally understood that folks want to roll credits, there are no tools for setting or even reporting roll rates in the titler: one just has to adjust things by trial and error. This stinks: if you're stuck with such a CG and need to produce for interlaced video, complain loudly to the vendor about their lousy non-video-aware tools, and then go look for a CG that does things right ( Inscriber Technology's CG is one of the few that does; you might also check out Pinnacle's TypeDeko on the PC, McRobert's Comet CG on the Mac, and Boris Graffiti on PC or Mac. These may offer proper controls... and there may be others out there as well. Let me know what you come up with and how well it works — or doesn't).
Codec Pathologies: Most titlers in nonlinear editors render nice, sharp text. That's just fine for display on a computer screen, but it's too sharp for either bandwidth-limited broadcast or for compression: DV, M-JPEG, MPEG, or the like. This is true whether or not the text is antialiased; even antialiased text can have sharp vertical, horizontal, and diagonal transitions with significant energy in spatial frequency bands outside the codec's comfort range.
Overly sharp text stresses the codec; in DCT-based codecs this results in “mosquito noise” or “feathering” artifacts that cause visual noise scattered around the immediate vicinity of the text. Moreover, the character of this noise varies depending on the relationship of the stressing image to the DCT block boundaries, which means that as your text moves (in a roll, crawl, or scroll) the mosquito noise surrounding the text will “fly around” just like a flock of hungry mosquitos. It's very annoying.
The trick is to prefilter the text so as to avoid these problems. Running a simple soften or blur filter over the text will make it look a lot worse on the computer screen — but it will actually improve its appearance going through the codec. Not a lot of softening is necessary, but a little bit almost always helps.
Bandwidth — or more precisely, an excess thereof — has been a CG problem since day one. Many CGs (even high-end broadcast CGs) simply render text, antialiased or not, into their frame buffers, then encode the results as a video signal and send it out. Unfortunately, the sharp horizontal luminance transitions across characters can contain significant energy at frequencies above the passbands for NTSC or PAL systems (or even the circuits in unencoded, component analog VTRs and terminal equipment), which causes ringing and overshoot in the signal (I've measured 20% overshoot on the outputs of some top-end CGs).
For example, if you set the peak white in your text at 80 IRE (for NTSC, or 80% in PAL), the overshoot will hit almost 100 IRE or 100%. Many CGs offer a default white value in their palette of 80 IRE, because anything brighter causes an overshoot beyond 100 IRE or 100%: this results in “sync buzz”, that annoying 60 Hz (50 Hz for PAL) buzz you'll get in over-the-air audio when overmodulated picture carrier bleeds into the sound subcarrier. [Amusing note: the hardware folks who designed the Abekas A72 were very careful to bandwidth-limit the video outputs to avoid this ringing and overshoot. As a result, you can use a peak white of 100 on the A72 with no problems. Of course, we got lots of complaints from New York producers who really liked that hard-edged, ringing video quality they got out of their Chyrons; you can't satisfy everyone...] Again, the solution to the problem is proper prefiltering: 100 IRE / 100% white is perfectly usable but only as long as you smooth off the sharp edges to prevent ringing.
Color choices are also important when designing titles. Sure, just like you I'd love to use a deep, saturated red — but it usually doesn't work out in practice.
First, the chroma bandwidth of all of our current production formats is at best 1/2 the luma bandwidth (in 4:2:2 digital video) and often only about 1/4 as good (4:1:1 or 4:2:0 DV; BetaSP, MII) or even worse (3/4", S-VHS, Hi8, VHS, Video8). Since most text is comprised of fine detail, there's not enough area for the color to fully express itself: what you'll mostly get are noticeable color bleeds of the text onto the background and vice versa.
Second, any time you encode the video as NTSC or PAL for composite display or for analog transmission (which as of mid-1998 is how most of us are seeing TV, Digital Satellite Systems and DVDs aside [and even then many folks are connecting DSS and DVD via a single-wire composite feed]), you'll get cross-color and cross-luminance artifacts at sharp transitions, especially when trying to use brightly-colored text. Often the dot crawl artifacts seen on such text will render it unreadable. What makes this worse is picking a text color that's at the opposite side of the vectorscope from the background: for a real howler, try red text atop a cyan background or magenta text on a green ground, and view it on a composite monitor: ouch!
What can you do? Sad as it might seem, you have to back off the saturation and go for more muted pastel tones. Also, picking colors in the same wedge of the vectorscope (yellow on red, or cyan on blue, for example) causes fewer out-of-band excursions of the color subcarrier, and minimizes dot-crawl artifacts.
It's critical to view your rendered text on a real, honest-to-goodness composite video monitor; the computer monitor (or even an RGB video monitor) showing a full-bandwidth uncorrupted RGB signal is no indication of what the text really looks like once it's been put on video.
The one seeming exception I've found to these overall guidelines is rendering yellow text atop blue or cyan backgrounds (at least in NTSC; I've not tried this with PAL encoding). This violates all the rules: I'll use fairly saturated colors for both text and ground, and they're opposite one another on the vectorscope. For whatever reason, this doesn't seem to cause as many problems as other, similarly pathological combinations. It could be that the yellow/blue change vector is fairly close to the B-Y axis, where humans' spatial color sensitivity is near a minimum; it could be that the Y signal excursion is not as great, so less cross-color appears; it could just be a personal preference and associated aesthetic blindness!
Last updated 2004.02.05