VHS -> svideo -> DV = Wavy video. Any ideas?

[Colmino]

Hey all. I've recently undertaken to convert all my old VHS stuff to DV, for eventual noise reduction and media archival. My setup is a SVHS deck running audio and svideo to a MiniDV camcorder which encodes and firewires DV video to the PC. After letting this setup run for a couple of tapes, I decided to take a look at the results.

I immediately noticed a problem. The playback software I used to investigate the video were WMP9 and Premiere Pro. Both of these perform simple deinterlacing on the fly. The result, visually, is wavy images. It's what you might expect to get if the first field of every frame (of the VHS video) were offset two pixels to the right (more or less), prior to deinterlacing. I'm actually sort of at a loss as to how to explain the result I'm seeing. When watching a static image like a DV recording of the VCR's "blue screen" (with "PLAY" in the upper-left corner), the problem persists, so it's not something wrong with the tapes. The waves do not move or crawl. They're frozen.

No combination of "always deinterlace", "reverse field dominance", etc. fixes the problem. The most that happens is the waves become less distinct.

I'll try attaching an image. Any suggestions, or hints as to what's causing this, would be appreciated. Thanks!

[jagabo]

That's NTSC dot crawl, not interlacing. Note each "band" is two pixels high.

[Colmino]

Hmm. I associate dot crawl with chroma / luma crosstalk. Also with contrasting colors as opposed to contrasting luminances. In this case, however, I utilized svideo, which has never suffered that sort of artifact as far as I've been able to tell. And the horizontal offsetting extends to the entire length of the video (check the edges, which are offset in a wave just like the rest of the video).

Anyway, if it's an issue with dotcrawl, and svideo isn't actually preventing that from happening, then what might be the solution? I'll incidentally regale that sending svideo from the VCR to a plasma display does not engender the interlace-like waves shown in the frame I posted.

[jagabo]

You're right, the major problem isn't dot crawl. But it's not a problem where one field is shifted sideways either. It's pairs of scanlines (one from each field) that are shifted.

Does this happen only with the VCR's chracter generator when there's no signal? Maybe it's something odd about the character generator?

I wouldn't trust a plasma TV as an analytical tool. The picture you see there is highly processed (deinterlaced, temporally and spacially filtered, etc).

[Colmino]

Does this happen only with the VCR's chracter generator when there's no signal?

No, it's consistent throughout the video. I used a shot from the VCR's self-generated output to keep things easy to discern as well as to definitively rule out problems with the tape.

While I readily admit that I can't figure out how this is happening, I admit I'm a little disappointed that this hasn't turned out to be an ultra-common issue with VHS -> svideo -> DV camcorder. I half expected to be scolded for being a newbie and not intuiting something basic which would solve everything.

[jagabo]

Try capturing from a DVD player or cable box using the same setup. That should help isolate the problem.

[Colmino]

I did do that, actually, using the same cables. The problem is nonexistent from any source but the VCR. While it may be tempting to point a finger at the VCR, I'll be quick to restate that the output as displayed on both a plasma and a 27 inch CRT is not exhibitive of any artifacting of this type.

[Colmino]

I'd probably be a lot closer to at least figuring out what's going on if Premiere Pro allowed the user to view frames as two fields, or view fields one at a time without processing, or something. There are dramatic and frustrating inconsistencies between the video Premiere Pro displays in its preview window and the actual video as might be seen in a media player.

[jagabo]

So you see this only on-screen in Premiere?

I noticed the shift varies within scanlines. It's not simply that pairs of scanlines are shifted right or left. Here's a 16x enlargment:

[Colmino]

So you see this only on-screen in Premiere?

No, the problem definitely also reveals itself during playback with WMP9. What I mean is that Premiere Pro's progressive rendering of frames in the preview window has been proving to be a less than accurate representation of what the video is actually doing. That's why I'd love to be able to force Premiere Pro to show me individual fields without processing. Too bad this far from inexpensive software just isn't that capable.

I noticed the shift varies within scanlines. It's not simply that pairs of scanlines are shifted right or left.

Good find. I hadn't noticed that myself. The explanation that I am leaning towards is that Premiere Pro's rendering is manifestly false, and the incongruous nature of the wave artifact is evidence of this.

Quick. Somebody port FCP to Windows.

[jagabo]

Try opening one of your DV AVI files with VirtualDub (enable it's internal DV decoder first with Options -> Preferences -> AVI -> Prefer Internal Decoders...). Export a frame with Video -> Copy Source Frame to Clipboard, then paste with some image editing software. That will show you a minimally processed image. Does it still have the same defect?

[edDV]

On first look the pictures look like line to line jitter.

If you cap from a cable or sat box are they vertically straight? This separates source vs. sampling issues.

[Colmino]

Try opening one of your DV AVI files with VirtualDub (enable it's internal DV decoder first with Options -> Preferences -> AVI -> Prefer Internal Decoders...). Export a frame with Video -> Copy Source Frame to Clipboard, then paste with some image editing software. That will show you a minimally processed image. Does it still have the same defect?

Alright, done. I'm far from adept at VirtualDub, but the video it shows me is identical to what Premier Pro and WMP9 show me. And the captured frame looks exactly the same as one captured from Premiere Pro.

This is a little baffling. DV video is not progressive. But all I can get from these applications is a progressive frame. And unfortunately that's no help in narrowing down what the heck is going on.

[Colmino]

If you cap from a cable or sat box are they vertically straight? This separates source vs. sampling issues.

I've captured from a couple of different sources now (Hi8 and DVD player, both via the same svideo cable). The problem does not surface in these cases. I've been thinking that it may have something to do with the lower resolution being generated by the VCR.

[lordsmurf]

DV video is not progressive. But all I can get from these applications is a progressive frame. And unfortunately that's no help in narrowing down what the heck is going on.

VirtualDub has a filter that can put fields side-by-side.

[jagabo]

Seeing individual fields won't help in this case. The problem isn't that one field is shifted to the side.

[Colmino]

It does help narrow down possibilities, at least. Thanks to some tips I was able to find a process in VDub which did the trick. Here is a shot of the two fields side by side (this time taken using a 50 foot svideo cable, just as an exercise in eliminating variables). Inexplicably, the fields themselves exhibit the two-pixel comb effect, apparently in precise sync with DV's vertical resolution. Is it just possible that the camcorder itself is responding to a token amount of noise by shifting literally every second scanline to the side? Note that the noise in this case is bad enough to reveal a netting pattern on the ostensibly pure blue backdrop. I've seen this pattern before, in other threads, but never heard anything definitive as to cause.

Anyway, I'll post this new image in the hope that it will make a lightbulb appear over somebody's head.

[edDV]

Do you see the same issue if the VCR is tuned to a stable source such as a TV channel? The blue screen indicates lack of signal and the VCR is in free run. This may be upsetting the sync lock circuits in the camcorder.

[lordsmurf]

It might just be the displayed numbers are bad. Is your video affected too?

[Colmino]

Strangely enough, when it is sending real video, the effect is less pronounced, as well as less uniform. It is still there to some degree. Even in the less than ideal example I provide below, you can see the waves in the "P" of "SLP" and the mostly red background showcases an alternating brightness from scanline to scanline.

Makes a person wonder if there's a SVHS VCR out there with firewire.

[lordsmurf]

I don't think you actually have an error here. The numbers just suck. The display is blocky and has dot crawl. The video image looks fine. It's about all you can expect from VHS.

[Colmino]

I'll try to get my hands on a very, very good svideo cable and see how the camcorder likes it. Perhaps I can further minimize the horizontal alternation.

[jagabo]

That new cap looks OK to me too. Slight differences from field to field are normal.

[deuce8pro]

I don't see any issues. It may be a good idea if you are capturing to turn the superimpose off on your vcr so you dont record "play" and "slp" anyway. I also would highly recommend Acoustic Research Pro II series svideo cables. I tried these recently (ones purchased off ebay for very little) and I thought they were excellent cables. Sharper with more clarity then my previous cables.

[Alan69]

Not an interlace problem. You have uneven timings coming from a VCR, and a DV input device that doesn't have a frame or line buffer before it writes to tape, so no way to adjust for the uneven timing. Inconsistent timings and no adjusting to the Hsync of each line = lines that aren't even to the edge.

Would take at least a line buffer on the output of every VCR to deliver a rock solid frame. Buffer each line, then output it at an exact timing vs the Vsync, or at least exact enough vs the last line's Hsync. They don't do that, Hsync for each line simply has to be close to right timing. An analog TV doesn't care, Hsync happens then retrace and line simply has to be accurate to it's Hsync, doesn't matter if timing changes some vs where the last Hsync was, and thus timing can also be loose back to the last Vsync. Hsync and then the line have to have good timing, relative to any other syncs they can be pretty loose. When reading the tape, Hsyncs can be even more off, from stretching tape or slightly different heads etc.

DV camcorder is a modern device, clearly yours need an accurate source, it's not adjusting to just each line's Hsync. Most capture cards also do this, so old or sloppy/cheap VCR tape has exactly this. My RC heli tapes from the early 90's do this on the AIW. Play them back on my analog 1902A monitor and the video is solid, lines are fine vs their Hsync but the AIW can't cope with the wide Hsync to Hsync variation. Got an ILO DVD recorder, it worked fine after firmware hack so the really far off Hsyncs didn't trigger the macrovision and stop the recording. Have to have some kind of incoming storage to do MPEG encoding, that lets it wait much longer before having to output anything, so it can deal with a much longer wait for the next Hsync and still keep things aligned.

It is specifically your variable Hsync source to a device that can't handle it. Bet your VCR output would look great on my 1902A or any decent analog TV. It'll even look great on most any modern TV. Why? Even the newest TV's generally can handle a much greater timing variation, if not they'll get tons of returns if people hook up a VCR. Likewise, your DV recorder probably works great with things that deliver a more stable line to line timing, which sounds like the case. The DV manufacturer knows many people will probably never even hook up to the svideo port anyway, doing this ok like a TV needs to is a low priority..


Old Commodore monitors were very good at this, even better than a good TV. I've even played back a tape on them and cammed the screen for some stuff, worked great and cheaper than a frame buffer. Of course that was before I got my ILO recorder, it does great.

Interlace problems get you 'teeth', looks like a comb on vertical edges. What you've got isn't an even displacement between two fields, it's a random edge displacement. Look at the D in discovery and the edge of the tape and numbers etc.

Think of your Vsync as up at the top of each field, and the Hsyncs as being in a line off the left edge of the screen, for these pictures the line of Hsyncs are jagged from their loose timing, and make any vertical line have the same jagged edge, your scanlines simply aren't aligned. If your DV was referring only to the most previous Hsync and aligning them to it's own fixed timing, you'd be getting the same good picture you get on other devices. Instead it's not adjusting each Hsync, or not enough, and you're basically capturing the variability of the Hsync timing of your VCR output, and encoding it into the DV video.

Find an input method that can handle the jitter. In fact, you can probably find a device to go between the VCR and DV and stabilize the timing. Wouldn't really require a full frame buffer, since it only needs to store or delay a line long enough to feed each one out with good timing to the previous/next sync. My ILO does great for recording it, but not sure if it'd work as a passthrough device like this or not, I just record since MPEG and DVD resolution are really fine enough for VHS source. Actually I think it would now that I think about it, even for live output of cable etc it's output is going through the MPEG engine. Sometimes it only displays every other frame and it takes a power cycle to get it back to 30 FPS, text scrolls look terrible when this happens so is very clear it does, and makes it clear even pass through live feeds are being buffered. Bet your tape would look fine with SVHS > ILO DVR04 > DV.. A real framebuffer would of course fix this, but even the simplest line or frame buffer built into something will do it, you may even have something else on hand that would work.

Difficult to be 100% positive about anything short of using your equipment, but from what you've described I'd bet this is it. VCR is fine as evidenced by working fine on other devices. Assuming the DV capture is great because it captures ok from other devices with their own great timing is off a bit, those don't even really test its ability to handle a imperfect input. It's a known weakness of VCR output, so for which is technically wrong it's definitely your DV is weak on input. But a secondary function and low use for a modern device, so it's no surprise. Other chipsets or designs of DV camcorder can probably handle it fine, but doubtful any engineer is going to lose sleep over it even for a high end cam, so it'll be pot luck instead of necessarily a 'better ones have it' sort of thing.

Damn wrote a book but I can type so not as bad as it seems.. I've just run into this on a few of my earlier input devices, so it's easy to relate. Was glad when I found the ILO and then the firmware hack came out, made it easy. Forget the 'perfect quality only' idea and get one or a similar good recorder with MV hack that can handle this, and just record at best or 2 hour resolution. You simply won't miss the quality difference from a VHS tape source, and you'll be able to start it up and still have your real tools to play with.

[jagabo]

Also, the character generator is rendering low resolution text.

[Soopafresh]

Alan69 - Good read, learned a lot. Thx.

[themaster1]

from what i know, DV has a system which is ALWAYS bottom field first & your vcr sends a video signal with "upper field first" so my guess is your DV camcorder fails to restitute in real time a perfect bottom field first interpretation.


just my guess..

[jagabo]

An analog video signal is neither top field first nor bottom field first. It's an alternating sequence of top and bottom fields. It can be captured as either TFF or BFF depending on which field the capturing device starts with. DV AVI is normally BFF.