Aliasing when capturing VHS

[tugatomsk]

I bought an Avermedia Game Capture HD II (due to budget constraints) which generates mp4 video files.

The recorded video quality of the Avermedia device in "576i optimal" (for VHS content) is good, but not great. The 8bit AVC average bitrate of only 7500 kbps is merely serviceable. VLC player plays it fine, though. The aspect ratio is 1:1, apparently, resulting in 720x576 video files. I guess it makes resizing easier?

The VCR being used is primarily a 2003 Panasonic NV-FJ623, with an older mono Sony SLV-135 whenever tracking becomes an issue.

The recording process is somewhat convoluted because I lack a composite to HDMi converter (I've ordered one, it just hasn't arrived yet). The signal from the VCR passes through a Sony DVD recorder (Sony RDR HX-710) via SCART. Then, the signal from the component output of the Sony recorder enters the Avermedia through the component input via a composite cable. It may seem terrible, but guess what, it works great, all things considered!

I'm trying to adapt the earlier avisynth script to these new mp4 files. I'm using Virtualdub 1.10.4 as a frameserver so I can check for errors.

Another issue is light aliasing present in the original VHS playback, like this, albeit not as strong:
https://forum.videohelp.com/threads/390999-aliasing-when-capturing-analog-Component-v-s-S-video

I tried figuring out if the aforementioned convoluted recording setup could be related to this. The conclusion is that it seems to be completely random, it doesn't happen all the time. I can't find a logical explanation. The tape in question was recorded in the late 80s with a long-gone National VHS VCR. There's no correlation with any of the cables used or the VCRs. Moreover, I used the Sony DVD recorder plenty of times in the past without aliasing issues.

To make matters worse, opening the avisynth script in Virtualdub is only sucessful if I don't use QTGMC, santiag (trying to test its anti-aliasing). It returns the error "File does not have a video stream"...

I even dumped the whole original mp4 in Virtualdub just so I could figure out if it was a case of fields swapped. I used "Field Swapping" in Virtualdub but it did not improve things.

Here's the avisynth script:

LoadPlugin("C:\Program Files (x86)\MEGUI\tools\avisynth_plugin\FFMS2.dll")
LoadPlugin("D:\USER\Documentos\IMPORTANT STUFF BACKUP\avisynth plugins\hqdn3d\hqdn3d.dll")

DirectShowSource("C:\Users\era uma vez a vida.mp4")
#mpeg2source("G:\WORKING\Duarte&co\Duarte e Companhia - 10 RTP memoria.d2v")
AssumeTFF()
#SwapFields()
#QTGMC( Preset= "Slower" )
QTGMC( Preset="Slower", MatchPreset="Slower", MatchPreset2="Slower", SourceMatch=3, Sharpness=0.9, TR2=3, Lossless=2 )
#(TR2= 0 for clean sources TR2=3 for noisy sources)
#SelectEven()
#SelectEven() maintains original framerate
#hqdn3d(ls=1.0, cs=1.0, lt=6.0, ct=1.0, restart=7)
#TurnRight().Santiag().TurnLeft()
#santiag is an anti-aliasing filter
LanczosResize(768,576)
Crop(10, 2, -16, -0)

Here's a sample video.
https://mega.nz/file/aZBSyQZY#cPYbb4OV8dOzM3oajvUt1-Eg-HzWg1ywo51OREItECs

[jagabo]

Your mega link is corrupt. The link to the other videohelp thread is corrupt too.

[tugatomsk]

Your mega link is corrupt. The link to the other videohelp thread is corrupt too.

Links fixed.

[jagabo]

Try this instead of QTGMC:

nnedi3(field=-1)

[tugatomsk]

Try this instead of QTGMC:

nnedi3(field=-1)

The aliasing was indeed eliminated. But there are still interlacing artifacts, especially on changing scenes.

What does that code do, to be exact?

[manono]

What does that code do, to be exact?

You could always look it up:

http://avisynth.nl/index.php/Nnedi3/nnedi3

nt field = -1

Controls the mode of operation (double vs same rate) and which field is kept. Possible settings:

-2 = double rate (alternates each frame), uses avisynth's internal parity value to start
-1 = same rate, uses avisynth's internal parity value
0 = same rate, keep bottom field
1 = same rate, keep top field
2 = double rate (alternates each frame), starts with bottom
3 = double rate (alternates each frame), starts with top

If field is set to -1, then nnedi3 calls child->GetParity(0) during initialization. If it returns true, then field is set to 1. If it returns false, then field is set to 0.

[tugatomsk]

What does that code do, to be exact?

You could always look it up:

http://avisynth.nl/index.php/Nnedi3/nnedi3

nt field = -1

Controls the mode of operation (double vs same rate) and which field is kept. Possible settings:

-2 = double rate (alternates each frame), uses avisynth's internal parity value to start
-1 = same rate, uses avisynth's internal parity value
0 = same rate, keep bottom field
1 = same rate, keep top field
2 = double rate (alternates each frame), starts with bottom
3 = double rate (alternates each frame), starts with top

If field is set to -1, then nnedi3 calls child->GetParity(0) during initialization. If it returns true, then field is set to 1. If it returns false, then field is set to 0.

I was just reading this. This is a fascinating discovery for me.

I tried to somehow decomb the remaining interlacing artifacts I had mentioned, using Telecide()... The results were both disappointing and good because it did try to smooth the artifacts, but there's always something remaining in the end. What is the correct way of dealing with them?

[dellsam34]

The right way is to capture the component output, Converting back to composite for capture or using composite to convert to HDMI for capture are lousy methods and are not intended for archiving, just a convenient way of getting the video from analog to the digital world.

[jagabo]

I saw no residual combing after:

ffVideoSource("era uma vez a vida (trim).mkv") 
nnedi3(field=-1)

Every other frame is a duplicate so you might follow up with SelectEven() or SelectOdd() to go back to 25p. And a lot of other cleanup.

[tugatomsk]

The right way is to capture the component output, Converting back to composite for capture or using composite to convert to HDMI for capture are lousy methods and are not intended for archiving, just a convenient way of getting the video from analog to the digital world.

If the signal is composite from the start, isn't it indifferent what cable is used on my Sony DVD component output? It's still a composite signal even if I changed to the proper component cable, right?

Shouldn't using the composite to HDMi converter & upscaler be the ideal situation (regardless of resolution changes)? Anyway, the Avermedia video capture also captures HDMi.


Don't take my questions personally, I just want to learn.

[tugatomsk]

I saw no residual combing after:

ffVideoSource("era uma vez a vida (trim).mkv") 
nnedi3(field=-1)

Every other frame is a duplicate so you might follow up with SelectEven() or SelectOdd() to go back to 25p. And a lot of other cleanup.

Here's a few examples or interlacing artifacts I get using your first suggestion:

[jagabo]

Those are chroma artifacts from handling interlaced chroma as if it is progressive. I suspect a ConvertToYV12() without interlaced=true. Or maybe the problem is in the source (your sample video was very messed up by your capture method). Upload a sample with those frames. And your entire script.

[tugatomsk]

I don't think I added ConverttoYV12 in any part of the script. I mean, yes, it's there, but it's not active.


Here's the new sample (from the original 3h30m video, as with the first sample):

https://mega.nz/file/fVJkBQYQ#8ZdF0ZDPG90S2RcN0ULhnSvfA1QM0_TRbJl7krS7UtU


Here's also the avisynth script I used implementing nnedi3:

LoadPlugin("C:\Program Files (x86)\MEGUI\tools\avisynth_plugin\FFMS2.dll")
LoadPlugin("D:\USER\Documentos\IMPORTANT STUFF BACKUP\avisynth plugins\hqdn3d\hqdn3d.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\Decomb.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\nnedi3.dll")
DirectShowSource("C:\Users\era uma vez a vida.mp4")
#
#converttoyv12()
#
nnedi3(field=-1)
#
#QTGMC
#AssumeTFF()
#QTGMC( Preset= "Slower" )
#QTGMC( Preset="Slower", MatchPreset="Slower", MatchPreset2="Slower", SourceMatch=3, Sharpness=0.9, TR2=3, Lossless=2 )
#(TR2= 0 for clean sources TR2=3 for noisy sources)
#SelectEven() maintains original framerate
#SelectEven()

[jagabo]

I think DirectShowSource() is screwing up the video. I don't get that at all:

LWlibavVideoSource("era uma vez a vida (piece II).mkv") 
Trim(1200,1349)
nnedi3(field=-1)

Generally, you should avoid DirectShowSource() as it's not frame accurate and dependent on your system setup.

[tugatomsk]

Generally, you should avoid DirectShowSource() as it's not frame-accurate and dependent on your system setup.

You're right, the problem is on my end, your video looks great. However, why does it look sped up?

Virtualdub crashed because of LWlibavVideoSource command. Is there a plugin that I'm missing? (I have never even heard of that command )

EDIT: SUCESS!! I found the LSMASHSource.dll and now everything runs smoothly!

Thank you very much!

[jagabo]

your video looks great. However, why does it look sped up?

Oh, sorry. I forgot that LWlibavVideoSource misinterprets the frame rate of your videos as double the actual rate. I was only looking at individual frames in an editor so I didn't notice it played too quickly. I should have added an AssumeFPS(25) to the script:

LWlibavVideoSource("era uma vez a vida (piece II).mkv")
AssumeFPS(25)
Trim(1200,1349)
nnedi3(field=-1)

I haven't checked if a newer version of LSMASH will fix that problem. By the way LWlibavVideoSource() only loads the video. If you want to process the audio too use something like:

a = LWlibavAudioSource("era uma vez a vida (piece II).mkv")
v = LWlibavVideoSource("era uma vez a vida (piece II).mkv")
AudioDub(v,a) # join video and audio into a single stream
AssumeFPS(25)
Trim(1200,1349)
nnedi3(field=-1)

With your MP4 sources you can use LSMASHVideoSource() and LSMASHAudioSource() instead. Those work with MOV and MP4 files and don't have to build an index file like the LWlibav equivalents (because MOV and MP4 already include the index internally).

<edit>
I just checked the latest LSMASH -- it has the same double frame rate problem with the sample. It may or may not have the problem with your MP4 source.
</edit>

[tugatomsk]

your video looks great. However, why does it look sped up?

Oh, sorry. I forgot that LWlibavVideoSource misinterprets the frame rate of your videos as double the actual rate. I was only looking at individual frames in an editor so I didn't notice it played too quickly. I should have added an AssumeFPS(25) to the script:

LWlibavVideoSource("era uma vez a vida (piece II).mkv")
AssumeFPS(25)
Trim(1200,1349)
nnedi3(field=-1)

I haven't checked if a newer version of LSMASH will fix that problem. By the way LWlibavVideoSource() only loads the video. If you want to process the audio too use something like:

a = LWlibavAudioSource("era uma vez a vida (piece II).mkv")
v = LWlibavVideoSource("era uma vez a vida (piece II).mkv")
AudioDub(v,a) # join video and audio into a single stream
AssumeFPS(25)
Trim(1200,1349)
nnedi3(field=-1)

With your MP4 sources you can use LSMASHVideoSource() and LSMASHAudioSource() instead. Those work with MOV and MP4 files and don't have to build an index file like the LWlibav equivalents (because MOV and MP4 already include the index internally).

<edit>
I just checked the latest LSMASH -- it has the same double frame rate problem with the sample. It may or may not have the problem with your MP4 source.
</edit>

Many thanks!

[dellsam34]

The right way is to capture the component output, Converting back to composite for capture or using composite to convert to HDMI for capture are lousy methods and are not intended for archiving, just a convenient way of getting the video from analog to the digital world.

If the signal is composite from the start, isn't it indifferent what cable is used on my Sony DVD component output? It's still a composite signal even if I changed to the proper component cable, right?

Shouldn't using the composite to HDMi converter & upscaler be the ideal situation (regardless of resolution changes)? Anyway, the Avermedia video capture also captures HDMi.


Don't take my questions personally, I just want to learn.

I had assumed you are using a combo VHS/DVD with component out, You definitely need a combo deck with component out or a S-VHS deck with S-Video if you are serious about archiving, But for learning purposes and sharing low quality versions of the video you should be good.

[tugatomsk]

I had assumed you are using a combo VHS/DVD with component out, You definitely need a combo deck with component out or a S-VHS deck with S-Video if you are serious about archiving, But for learning purposes and sharing low quality versions of the video you should be good.

I remember those VHS/DVD combos back in the day, but I didn't know they had component output.

My Sony DVD recorder also has S-Video output (besides component output and L/R audio output, the ones currently in use).

Which one is superior: S-Video or component? Should I get true component cables for the same setup?

[lordsmurf]

I bought an Avermedia Game Capture HD II (due to budget constraints) w

Just FYI, a better card would have cost the same or less.

You're using the wrong tool for a capture task. The result is crappy video, as you're seeing, and as we're seeing. The damage is done, you can't unring the bell. Redo the captures with a better card, as you're wasting your time on this method.

You definitely need a combo deck with component out

I remember those VHS/DVD combos back in the day, but I didn't know they had component output.

They don't.
Read my other post here: https://forum.videohelp.com/threads/398459-VHS-C-Advice#post2594905

The output on the back of the box isn't necessarily (ie, almost never is) obeying chain of custody of the data. It's immediately converted from Y/C (VHS native) to composited video, like any other consumer VHS VCR, and is then flung into a cheap conversion that spits out HDMI/component. I've never seen consumer units where the Y/C is maintained separate internally, aside from S-VHS combo decks. The DVD player outputs actual HDMI/component, but the VCR is composite both internal and external.

Whether the VCR>DVD (recorder) dub is Y/C is debatable. Even so, it can be processed in nasty ways. For example, the favored ES10/15 units (non-combos) have posterization and aggressive NR that can negate restoration efforts, which is why it's ideally only used for tearing issues and not always-on use.

Funai made most combo units, and those were put together with chicken wire and duct tape.

[lordsmurf]

<dupe>

[tugatomsk]

You're using the wrong tool for a capture task. The result is crappy video, as you're seeing, and as we're seeing. The damage is done, you can't unring the bell. Redo the captures with a better card, as you're wasting your time on this method.

I realized from the start it wasn't the best tool, but given my limited knowledge and hardware constrictions on my PC, this was the most balanced option. Besides, the aliasing doesn't always manifest itself. As I said, it seems random with each tape, even with tapes recorded during the same time period and with the same machinery.

I wouldn't say the quality is crap, though. I know it's a bit starved, but that's it, at least to me.

There's one thing I forgot to mention, though. The aliasing - when it occurs - is present way before reaching the Avermedia. I tested connecting the VCR directly to my LCD and, to my surprise, it was present. So it's not an issue with the Avermedia device, otherwise the aliasing would be recorded in the Avermedia every time, which doesn't happen all the time. As I said, it apparently depends on the tape itself, regardless of the VCR I used (the current Panasonic and the oldie Sony). But the aliasing never occurred when I played the same tapes in the past in in the then new Sony VCR.

When the aliasing doesn't manifest itself, the picture quality is actually really good, considering it's a nearly 30-year-old videotape.

Just FYI, a better card would have cost the same or less.

You mentioned appropriate capture cards in the same price range of the Avermedia. Would you care to provide some examples that don't require onboard PC installing?

The output on the back of the box isn't necessarily (ie, almost never is) obeying chain of custody of the data. It's immediately converted from Y/C (VHS native) to composited video, like any other consumer VHS VCR, and is then flung into a cheap conversion that spits out HDMI/component. I've never seen consumer units where the Y/C is maintained separate internally, aside from S-VHS combo decks. The DVD player outputs actual HDMI/component, but the VCR is composite both internal and external.

So VHS/Betamax video capture should ideally be made with S-VHS and/or Super Betamax due to them featuring S-Video output?

[dellsam34]

So VHS/Betamax video capture should ideally be made with S-VHS and/or Super Betamax due to them featuring S-Video output?

You got that right. The signal path from the original source (camcorder, VCR, Studio) is recorded on tape in a format called component Y/C, Y is luma (black and white) and C is chroma (color layer), each one in the Mhz range frequency, Then the C signal gets downsampled to few Khz and encoded withing the Y signal to fit on tape, When the tape is being played back by the end user VCR the chroma signal gets converted back to MHz range with slight loss and the Y/C component signal is restored and then being output via a socket called S-Video (pro VCR's use two BNC connectors one for Y and one for C signals).

If your VCR doesn't have S-Video output, it will do one more step to the signal that further degrades it, It takes the Y/C signal, combine it into one signal called CVBS or composite and output via a yellow RCA connector.

I used layman words to make it easier to understand, hope it helps.

[tugatomsk]

So VHS/Betamax video capture should ideally be made with S-VHS and/or Super Betamax due to them featuring S-Video output?

You got that right. The signal path from the original source (camcorder, VCR, Studio) is recorded on tape in a format called component Y/C, Y is luma (black and white) and C is chroma (color layer), each one in the Mhz range frequency, Then the C signal gets downsampled to few Khz and encoded withing the Y signal to fit on tape, When the tape is being played back by the end user VCR the chroma signal gets converted back to MHz range with slight loss and the Y/C component signal is restored and then being output via a socket called S-Video (pro VCR's use two BNC connectors one for Y and one for C signals).

If your VCR doesn't have S-Video output, it will do one more step to the signal that further degrades it, It takes the Y/C signal, combine it into one signal called CVBS or composite and output via a yellow RCA connector.

I used layman words to make it easier to understand, hope it helps.

Thanks you for the detailed explanation. ��

Now the question is: where am I going to find a Super VHS VCR nowadays, let alone a fully functioning one? (Especiallu in my country?)

[jagabo]

Also, I believe your satellite box or RGB-to-S-Video converter is performing a dup-field deinterlace -- that's the root cause of the aliasing.

[tugatomsk]

Also, I believe your satellite box or RGB-to-S-Video converter is performing a dup-field deinterlace -- that's the root cause of the aliasing.

I thought something like that as well, but then I performed a test: I bypassed the Sony DVD and connected the VCR directly to the Samsung LCD with the same SCART cable (with a special adapter that came along with the LCD) and the aliasing persisted, looking exactly the same.

Nnedi3 did a tremendous job fixing the aliasing and deinterlacing properly. However, I found out that QTGMC provides the same results. Anyway, it's good to become aware of alternatives.

[tugatomsk]

Howver, I detected another issue from the same episode:

LINK:
https://mega.nz/file/HARHzKDK#TiQegOneIevUH2elHGGFDcpb4hb0YUsirVxXJw-D8hk

The red colours are slowly and constantly pulsing. I have no idea why this occurs. In fact, it's the only video where I detected such a thing.

Does any of you know the potential source/reason for this issue? Are there filters that can help mitigate it?


EDIT: I forgot to add the script I used (listed below).

LoadPlugin("D:\USER\Documentos\IMPORTANT STUFF BACKUP\avisynth plugins\hqdn3d\hqdn3d.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\Decomb.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\LSMASHSource.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\nnedi3.dll")
LSMASHVideoSource("c:\users\era uma vez a vida.mp4")
AssumeFPS(25)
trim(127800,128800)
AssumeTFF()
QTGMC( Preset= "Faster" )
#SelectEven()
hqdn3d(ls=1.0, cs=1.0, lt=5.0, ct=1.0, restart=7)
#ReduceFlicker()
#Spline64Resize(960,720)
#nnedi3(field=-1)
#nnedi3_rpow2(rfactor=2)
#eedi3()

[tugatomsk]

After some work and research, I finished an avisynth script that produced rather good results, all things considered.

But there's something that's keeping the output video from being perfect: the final aspect ratio.

LWlibavVideoSource("G:\WORKING\era uma vez a vida.mkv")
AssumeFPS(25)
AssumeTFF()
#QTGMC( Preset= "Slower" )
QTGMC( Preset="Slower", MatchPreset="Slower", MatchPreset2="Slower", SourceMatch=3, Sharpness=0.9, TR2=2, Lossless=2 )
SelectEven()
Overlay(GreyScale(last), last, x=-3, mode="chroma")
LanczosResize(768,576)
Crop(20, 4, -12, -8)
hqdn3d(ls=1.0, cs=1.0, lt=6.0, ct=1.0, restart=7)

As you can see, I tried to transform the original square-pixel 720x576 resolution into the resolution that simulates the original PAL PAR, ie, 768x567. I then cropped as needed, including at the bottom due to it being a tape recording. Cropping after the resize shouldn't change the PAR, right?

Anyway, for some reason, the circles and spheres in the output video didn't turn out perfect.

Here are the original video and the output test.

LINKS FIXED!

original piece:
https://drive.google.com/file/d/11kF13HJCpkJ1Qa9ZBbGqMWOzfb44mDQt/view?usp=sharing

output:
https://drive.google.com/file/d/1SVpA9ZwLCF4pbfU9TVazKHZs8DzQuyiG/view?usp=sharing


What am I missing?

[davexnet]

After some work and research, I finished an avisynth script that produced rather good results, all things considered.

But there's something that's keeping the output video from being perfect: the final aspect ratio.

LWlibavVideoSource("G:\WORKING\era uma vez a vida.mkv")
AssumeFPS(25)
AssumeTFF()
#QTGMC( Preset= "Slower" )
QTGMC( Preset="Slower", MatchPreset="Slower", MatchPreset2="Slower", SourceMatch=3, Sharpness=0.9, TR2=2, Lossless=2 )
SelectEven()
Overlay(GreyScale(last), last, x=-3, mode="chroma")
LanczosResize(768,576)
Crop(20, 4, -12, -8)
hqdn3d(ls=1.0, cs=1.0, lt=6.0, ct=1.0, restart=7)

As you can see, I tried to transform the original square-pixel 720x576 resolution into the resolution that simulates the original PAL PAR, ie, 768x567. I then cropped as needed, including at the bottom due to it being a tape recording. Cropping after the resize shouldn't change the PAR, right?

Anyway, for some reason, the circles and spheres in the output video didn't turn out perfect.

Here are the original video and the output test.

original piece:
https://drive.google.com/file/d/11kF...ew?usp=sharing

output:
https://drive.google.com/file/d/1SVp...ew?usp=sharing


What am I missing?

Your links are not working ...

[jagabo]

After some work and research, I finished an avisynth script that produced rather good results, all things considered.

But there's something that's keeping the output video from being perfect: the final aspect ratio.

LWlibavVideoSource("G:\WORKING\era uma vez a vida.mkv")
AssumeFPS(25)
AssumeTFF()
#QTGMC( Preset= "Slower" )
QTGMC( Preset="Slower", MatchPreset="Slower", MatchPreset2="Slower", SourceMatch=3, Sharpness=0.9, TR2=2, Lossless=2 )
SelectEven()
Overlay(GreyScale(last), last, x=-3, mode="chroma")
LanczosResize(768,576)
Crop(20, 4, -12, -8)
hqdn3d(ls=1.0, cs=1.0, lt=6.0, ct=1.0, restart=7)

As you can see, I tried to transform the original square-pixel 720x576 resolution into the resolution that simulates the original PAL PAR, ie, 768x567. I then cropped as needed, including at the bottom due to it being a tape recording. Cropping after the resize shouldn't change the PAR, right?

Anyway, for some reason, the circles and spheres in the output video didn't turn out perfect.

Here are the original video and the output test.

original piece:
https://drive.google.com/file/d/11kF...ew?usp=sharing

output:
https://drive.google.com/file/d/1SVp...ew?usp=sharing


What am I missing?

Yes, your links aren't working. But...

In a PAL ITU cap only a 702x576 portion of the frame corresponds to the 4:3 image. A little extra is captured (a total of 720 horizontally) in case the cap or source is off center. So you need to crop to 702 (704 is often considered close enough) before resizing to 768x576. Or you can resize to 788x576, then crop away the black borders. For an NTSC cap the active 4:3 picture is in a ~704x480 portion of the 720x480 frame.