Horizontal Red and Green Lines (GV-USB2)

[fundo]

Hello there!

I have some trouble with my current setup for digitizing VHS family tapes. I'm located in Germany, the tapes are PAL. I'm using a Panasonic NV-HS830 directly connected to the capture card via S-Video. As far as I understand, this device doesn't feature any TBC functionality, but I'm not sure. How can I confirm?

For capturing, I have tried:

• EasyCap: Overall low quality, 4:2:0 subsampling
• Hauppauge USB-Live2: Good quality, audio clipping, settings are not persisted (probably a defective device?)
• I-O Data GV-USB2: Good quality

The GV-USB2 is the clear winner for me. Sadly, I am observing horizontal red and green stripes, but only when capturing with the GV-USB2. The stripes are barely noticable at original playback speed because the red and green parts are alternating. Interestingly, the occurrence and distribution of these stripes is the same when capturing the same scene repeatedly. But after a reboot of my PC and the VCR, the pattern changes. Sometimes, it is gone almost entirely. The capture settings are the same every time, and I haven't (yet) investigated whether it is the restart of the VCR or the PC or the capture device changing the pattern. I am capturing with VirtualDub2, but capturing with AmaRecTV gives the exact same result as long as I don't restart my setup.

I have attached two clips and frames of the same scene. Both are recorded with the same hardware and software setup, but a restart of my system has happened in between. The stripes are visible in capture_1 (and the respective frame), especially in the sky.

What could be the root cause for this behavior? Is it the lack of a TBC? Then why am I not seeing it with other capture devices? Or is my capture card defective? Any advice or hint is welcome!

Thank you in advance, and please let me know if I missed out on sharing some crucial info.

fundo

[fundo]

Hello again, I have now tried several times to reproduce the case in which the recording doesn't show the lines. Sadly, I have failed. I have power cycled the VCR, the capture device, the PC multiple times in all possible combinations. The lines are now there in every recording, and recording the same tape multiple times leads to the same pattern. Just to add some more clarity as to what I'm talking about, I'm attaching a frame where it is more obvious. The pattern appears in bright areas, especially the sky, and it also appears on vertical edges, especially those between dark and bright areas. Does anyone have a hint for me?

[Attachment 87996 - Click to enlarge]

[Sharc]

The HS830 has no TBC, therefore you get the horizontal wiggling. Watch the jittery poles.
The horizontal stripes are probably baked onto the tape by the camera. Maybe PAL Hanover bars, but I am not sure. Also, the 2 fields come with a sligtly different hue.
For capture_1 you should probably adjust the luma level (-> 'brightness' and 'contrast' procamp settings of the GV USB-2).
You can improve the stripes in your capture using vinverse().
Something to begin with:

AVISource("capture_1.avi")
ConverttoYV16(interlaced=true)
levels(32,1.1,200,0,235,coring=false)  #for demo only. Should be set right with the procamp settings of the GV-USB2
separatefields()
vinverse()
weave()

As your HS830 has no TBC you could use a DVD recorder in passthrough as a "TBC workaround" to eliminate the wiggling/jitter.

[fundo]

Hi Sharc, thank you so much for your analysis and your sample script! You're right, the proc amp settings are not optimized for this tape, yet. Your observation with the hue being different between the two fields holds true even for the recording in which the combing doesn't appear (capture_4.avi in the original post). Thanks a lot for the hints. I'll deal with those things later.

Thanks for pointing out that the jittery poles indicate that a TBC would be helpful. I'll try to get my hands on one of them. There seem to be many threads like this. Is there by any chance a thread which explains which models are generally appropriate?

But now, back to the color combing. I don't think it is baked into the tape, else I wouldn't be able to occasionally (very rarely!) record the same scene without the lines using the exact same setup and configuration (see capture_4.avi in the original post). In order to confirm this, I just wanted to switch from S-Video to Composite or maybe to a different (worse) VCR that I have access to. And out of the blue, before I even started this test, the lines are gone again in the original setup. See capture_9.avi and attached capture_4_frame_59.png, but it's especially obvious in clip_2_capture_2_frame_50.png.

I have checked what is required to trigger the combing again. I have rewinded the tape, ejected the tape, power cycled the VCR (pulling the plug), restarted VirtualDub2. Only after power cycling the capture device, the issue reappeared. Switching to Composite, the issue is still there. I have tried power cycling the capture device and the VCR again multiple times in any potential order, but the issue is there every time (Composite and S-Video).

To me, it looks like it is an issue with the GV-USB2 unit I have. What do you think?

[Aquilsas]

Hi there,

I've had the exact same issue with my GV-USB2, although I'm now sure it's not a device/hardware problem but something regarding my PC (O.S. maybe? Drivers?), as my Pinnacle 710 also produces those horizontal lines. In addition, I have recently lent my GV-USB2 and the person using it doesn't have this problem on his laptop.

[Sharc]

Hanover bars of PAL video:
https://en.wikipedia.org/wiki/Hanover_bars

[jagabo]

It looks like Hanover bars to me.

SeparateFields()
MergeChroma(Blur(0.0, 1.0).Sharpen(0.0, 0.7))
Weave()

[fundo]

Hanover bars of PAL video:
https://en.wikipedia.org/wiki/Hanover_bars

Thanks for sharing some more info on Hanover bars. The screenshot you've provided is a huge help, and explains exactly what I'm observing.

It looks like Hanover bars to me.

SeparateFields()
MergeChroma(Blur(0.0, 1.0).Sharpen(0.0, 0.7))
Weave()

This piece of code fixes the issue, which to my understanding confirms that it's Hanover bars.

Sharc, jagabo, thank you so much for identifying this issue!

But of course, I would prefer not having this issue in the first place. I have applied jagabo's commands to capture_1 and then inspected the chroma planes. When comparing them with the chroma planes of the unmodified capture_4, the post-processing seems inferior (e.g., less sharp and detailed). Is there a software-based method that would be on par with the non-affected capture?

Aquilsas's statement seems to confirm my experience that it doesn't appear always. Sadly, I don't understand the origin of the Hanover bars well enough to make sense of this. Does this mean it is not baked into the tape, but induced by the VCR or GV-USB2? Or does it mean that it is indeed baked into the tape, but VCR and GV-USB2 don't reliably manage to mitigate it? Would a TBC improve the situation?

[Sharc]

Aquilsas's statement seems to confirm my experience that it doesn't appear always. Sadly, I don't understand the origin of the Hanover bars well enough to make sense of this. Does this mean it is not baked into the tape, but induced by the VCR or GV-USB2? Or does it mean that it is indeed baked into the tape, but VCR and GV-USB2 don't reliably manage to mitigate it? Would a TBC improve the situation?

As I understand it the issue can in principle arise at any stage of the analog PAL YUV signal treatment
- The PAL signal (V component) may be incorrectly generated but correctly decoded (-> problem with the source)
- The PAL signal (V component) may be correctly generated but incorrectly decoded (-> problem with the decoder, e.g. simplified decoder due to royalty restrictions)
(- or a combination of the 2 above)

I have some doubts that the GV-USB2 is the culprit as this would have materialized for all PAL sources, and there would have been many complaints in the past.
I have seen the problem with dubbed PAL tapes. If I remember correctly it has also been observed for certain SONY camera models - don't quote me on that but perhaps search the forum(s).

There is not much you can do about it but fixing it in post processing with a script, IMO. The chroma merge resolution/sharpness compromise should not really matter much for VHS sources, it is more or less what the correct decoder would have done anyway by averaging the 2 scanlines.
A VCR with TBC would not help IMO. It would solve the jitter/flagging problem though.

It's my best guess. Maybe someone more knowledgable will chime in ......

[c24]

Hi,
I was recently testing an old pci wintv card with linux and i have a similiar problem, it also happens on the internal analog tuner.
I'm also curious to know why it happens, if it's an hardware or driver issue.
First image is blue screen from vcr, second image is dvd player background, third image a random movie played on the dvd (all PAL obviously).

[jagabo]

Hanover bars are the native way color is encoded in PAL system. It's even in the name: Phase Alternating Lines. The chroma carrier's phase is inverted on every other line of a field. To get the true color of a pair of lines you must blend the chroma of those two lines together. The code I gave earlier does that in a crude but fast fashion, blurring the colors slightly. You can get more precise blending with more sophisticated algorithm.

[jagabo]

Here's an algorithm that eliminates the hanover bars with less blurring:

LWLibavVideoSource("capture_1.avi") 
AssumeTFF()

SeparateFields()
src = last # remember luma
SeparateRows(2)
Merge(SelectEven(), SelectOdd())
SelectEvery(1,0,0)
WeaveRows(2)
MergeChroma(src, last) # restore luma
Weave()

# from here you can deinterlace if wanted