I hope the title is right and I hope I've done everything else right - I am a bit of a noob!
I have a VHS tape which has on it some 20 year old material from a consumer camcorder.
I am capturing the material digitally via:
JVC HR-S9500 VCR
TBC-1000 time base corrector
ATI AIW 9800 PRO
PC fast enough to keep up
The effect I am going to describe is independent of all this kit - I still see it with a different VCR, no TBC, DV capture via a DAC-2 on a different PC using WinDV.
I see horizontal lines. I know this is to do with how the picture is made. I don't FULLY understand how lines in the analog PAL VHS signal are translated into lines of pixels in a digital frame. But I know they are there. I have read up about inter-lacing; I understand that it is probably better not to de-interlace and rely on authoring/viewing software to deal with translating the interlaced source into the best picture to view.
But it's not that the lines are THERE, it is that my picture is kind of fuzzy, and one of the things that seems to be making it fuzzy is that the lines are moving slightly out of sync which each other, ie shifting from left to right, as I go from frame to frame. If I DO look at it through a deinterlace filter (Virtualdub), the lines disappear but there is an obvious left to right blurriness of vertical borders - so the defect is there, it's just not so clear what makes it up.
I get the same effect from a consumer pre-recorded VHS video, though less pronounced.
I have put a 10 frame sample in "My Files": http://files.videohelp.com/u/161331/ShedTest.avi
(hope I've done that right). You can see the effect in the top left quadrant, particularly zooming in and looking at the red window and the left-hand vertical edge of the shed.
So my questions, humbly, are:
(i) What is the left to right shifting of the lines?
(ii) Why is it more pronounced in one tape, though still there, than another?
(iii) Is there any way I can remove/reduce it?
In considering the last question, I've read up about and played with various editing software - Premiere Pro, Virtualdub, AVISynth. Cleaning up video seems to be mainly to do with filters which remove or obscure "noise" of one sort or another - this seems to be more of an "artifact" and maybe it is a well-known one which someone has found a solution to in the past.
+ Reply to Thread
Results 1 to 7 of 7
You did realise that anyone you replies needs to see a short sample video but 10 frames really takes 'short' to a new level.
Yes, there is interlacing present - I would be more surprised if I did not see it. De-interlacing, as you notice, does soften the image.
But your sample worries me more than that. Can not quite put my finger on it but to start with is this sample a stream copy of the original capture or simply vdub's uncompressed output. Even then the file size does not appear to be compressed(well not as I know it to be) so what is it ? Part of the problem could be in the method of capture so what settings did you use ?
This can't really be fixed in software. You need access to the horizontal sync pulse which is no longer available after capturing. There have been some attempts to fix the jitter by adjusting the length of the video between the black bars at the left and right -- but your capture device doesn't have a black bar at the left. And even when the video has both bars, the filters didn't work very well. They often made the video much worse. And with pictures that are dark at the edges they can't tell where the bars are so they totally mess up.
DB83: Thanks for looking at this. The sample file is captured with the ATI card and MMC software at the highest resolution, AVI. I think I used a lossless compresser (huffyuv). I figured to get as much of the original material, as big as possible, as unprocessed as possible, to give the most chance of seeing the effect. Then I trimmed off 10 frames in Virtualdub to post. Only 10 frames because (a) not to have a huge upload/download and (b) this was enough to see the thing I was talking about - load it into Virtualdub and step through the frames. I have captured a few different ways and it's always there. I could produce another sample if, factoring in jagobo's comment, you still think it would help.
Jagabo: Thanks enormously for your thoughts. There is some kind of line-based TBC on my VCR and this was switched on. It doesn't seem to make any difference off or on. It's interesting you should suggest line-based TBC - when I read up on these it seemed that line-based TBC's weren't much use and one should get a frame-based one - so I have the Datavideo TBC1000. Your explanation makes sense to me - I expect someone transferred from the original camcorder material to the VHS tape using a cheap VCR. With a pre-recorded cassette I see a tiny effect from my (not so cheap) VCR. With the ex-camcorder material, I see the combined effects of both. Those Panasonic ES10 machines are all over ebay for not much $ (£ for me). And I don't need to worry about worn moving parts or clapped out lasers to use the pass-through. On the other hand, it's adding another intermediate step in the chain. Do you think it would really do some good, given that most of this "horizontal time-based jitter" is probably coming from what's on the tape rather than from my VCR? In fact, would this step make any difference at all to jitter which is already in the tape?
No need for another sample for the current issue as jagabo has nailed the issue.
Not relevant to your problem but something you should consider is your use of virtual dub if you intend to do any serious editing with it. Like I said before, whatever your original source was (you can check that by running the capture in mediainfo) your sample most definitely was not - just do that same exercise with that to see what I mean. There is no way that 10 frames huffyuv would use nearly 12 meg. Uncompressed video is close to that(2 gig per minute IIRC) so maybe you captured uncompressed or exported uncompressed from vdub which is a waste. But there is no need for that. Lossless lagarith or huffyuv is sufficient and stream copy out of virtualdub.
The shed sample was uncompressed, 24 bit, RGB.