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

[Aquilsas]

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

[Attachment 88625 - Click to enlarge]

I'm sorry to bother, but I have absolutely no experience with Avisynth and I can't get to work any of the codes shared here.

Am I missing something?

Also, I'm attaching to this post a sample of my raw AVI file in case that helps to determine if it's fixable or not. Maybe the way or the format I captured the video made those lines "bake" into it?

Thanks in advance for any help.

[jagabo]

I may have a chance to look at the sample tomorrow. But your sample image is showing a frame much larger than the expected 720x576. Did you scale it before running the script? The script must be used on the original 720x576 video.

[Aquilsas]

Nah, I re-checked it just in case it and it was indeed captured at 720x576. It's the AvsP interface that displays it larger than that by default, IDK why.
And yes, if happen to have the chance to view it yourself, I'd truly appreciate it

[jagabo]

Hanover bars aren't the main problem with that video. Time base errors are causing problems with the chroma decoding. Capturing with a better line-TBC might help. If not, converting to greyscale() is about the only fix.

[Aquilsas]

Oh, I see... Well, it's an EP recording after all, so I knew from the start it wouldn't be easy.

In fact, I just tried with a different tape in much better conditions (this time SP) and the Avisynth algorithm worked this time. No hanover bars.

Thank you so much for your time and your intervention!

[WhiteboyUltima]

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

Sorry to revive a thread (and maybe I will make a new post once I have a solution), but I have what I'm pretty sure are Hanover bars that I am so close to solving, yet I need some help. In fact, I could possibly contribute to the Hanover bars literature online, because out of pure frustration at the lack of information on the topic, I've written a guide on how to solve the issue and tried to make it as easy as possible to follow. I used your code in that guide, but it's not quite working.

I cannot finish or publish such a guide until I know it actually works.

I have a powerful new computer - Windows 11 32GB RAM and Ryzen 9800X3D CPU, using a Samsung 990 Pro M.2 NVMe SSD.
I capture with an IO-Data USB-GV2 using weave (pass through i.e. no deinterlace) from my 6 head VCR player.
I have Hanover bars on 2 VHS SP videos - one professionally produced and one that could've been a home transfer from MiniDV onto VHS, not sure. Both are from around 1988-89.

Setup and workflow: PAL_I (UK region as far as I know since these are UK tapes). I am recording uncompressed using VirtualDub 1.10.4, not deinterlacing (yet), straight to 720x576 at 25FPS to AVI format. This is the requirement for the above code, from what I can see. Not sure if the colour type matters - I went with defaults (which I believe is YUYV).

Here's what my raw capture, interlaced 720x576 AVI looks like, very obvious Hanover bars that are also visible watching the tape on a TV (but when you do that, they are hard to see unless you pause the footage and then the lines appear to run down the screen every second or so). The Hanover lines are there throughout the whole 20 min video but mostly only visible on large areas of a single colour, like the dress, turquoise background, and red sign in these screenshots.

(Click to view full screen)

[Attachment 89825 - Click to enlarge]


Next, my videos needed deinterlacing which I am doing with QTGMC in AVISynth as per below and that works very well. However, the Hanover removal code doesn't seem to do anything.

Here are the different things I've tried (running scripts in VirtualDub2, but should be the same for the older version of VDub):

1. Only applying the Hanover script above (seemingly did nothing)
2. Only applied QTGMC script (deinterlaced successfully but Hanovers remained)
3. Applied 2 separate scripts: first for Hanover removal, then took that resulting video and ran the QTGMC deinterlace script (the resulting video was deinterlaced but not de-Hanovered)
4. Applied 2 separate scripts: first for QTGMC deinterlacing removal, then de-Hanovering (the resulting video was same as in 2 & 3: deinterlaced but not de-Hanovered)
5. Applied de-Hanovering and then QTGMC all in the same script, as per below (Strangely, this took only as long as removing Hanovers, so the QTGMC didn't work - the resulting footage is not even deinterlaced, so something is wrong here. Looks closer to my raw footage, however unlike that, when I play it in VLC and apply a real-time YADIF 2x deinterlace, it actually does a good job of removing Hanovers, perhaps at the expense of more blurriness and it's not 50FPS).


In all cases I am still seeing the Hanover bars in my result. I'm even seeing them in the 2nd video preview window before I save the AVI. Oddly, when I view any of these results in VLC and pause, the image flickers a bit so it's hard to get a screenshot. Not sure what that's about - it happens even when I am not applying a real-time deinterlace filter in VLC (because it's already been deinterlaced at this point). And when I watch the videos in Windows' new Media Player, some of the Hanover bars do seem less pronounced (like the red sign) but others (like the dress) do not. It could be that Media Player is applying some filter that I can't toggle, like another deinterlace, which is perhaps blurring things.

The strange thing is, I remember doing an earlier test on the same VHS tape after it had already been deinterlaced with a basic YADIF method, this time using VLC media player to run the de-Hanover script (crude as you have to watch it in real-time and hit the record button), but the result from that seemed to have no Hanover bars - or could simply be that I was deinterlacing twice which made things a bit blurrier.

I do notice that when I watch the above resulting deinterlaced and de-Hanovered videos in VLC and apply a real-time YADIF filter when viewing (so I'm de-interlacing twice which is wrong) - the result is that the Hanover bars seem mostly gone, but the video flickers when playing (a result of deinterlacing an already deinterlaced video in real-time?) and the bars are probably only gone due to blurring or similar effect.

This is the script I am running that I thought world work. The only modification I've done is to retain audio, I loaded the video and audio streams separately.

Video = LWLibavVideoSource("G:\Video\Wedding Video Processing\My Video.avi")
Audio = LWLibavAudioSource("G:\Video\Wedding Video Processing\My Video.avi")
return AudioDub(Video, Audio)

# Start removing Hanover bars
AssumeTFF() # Top field first, alternatively use BFF
SeparateFields()
src = last # remember luma
SeparateRows(2)
Merge(SelectEven(), SelectOdd())
SelectEvery(1,0,0)
WeaveRows(2)
MergeChroma(src, last) # restore luma
Weave()

# QTGMC deinterlacing - which I usually perform separately as per above methods
QTGMC( Preset="Slower", ShowSettings=false )

Here's the result for methods 1-4 above - nicely de-interlaced but Hanover bars remain, if perhaps a bit softer in some areas like the red sign:

(Click to view full screen)

[Attachment 89826 - Click to enlarge]


Questions
Am I doing this right? removing Hanovers as per jagabo's script and then applying QTGMC deinterlacing, in that order? Why does QTGMC only work if I apply it in a separate script after first running the de-Hanover script? Is it some QTGMC setting that is the issue? Why can I still see Hanover bars in all my results?

I am keen to get this wedding video and my other 40 min video with similar issues sorted. And then publish a guide on these forums. Thank you

[Sharc]

Upload a snippet of your unprocessed capture so someone may take a look. The tapes seem to have been edited ....
(What was your videocam and VCR model? Original tapes or copies?)

[jagabo]

Your script isn't doing any filtering because you have

return AudioDub(Video, Audio)

right after importing the video and audio. Get rid of the "return".

[CaptureCraft]

WhiteboyUltima, you need to use a DVD recorder as a pass-through device during the capture process. It would eliminate/clean up a lot of issues, including Hanover bars.