Criticise my script for VHS capture.

[poisondeathray]

There seem to be a lot of bugs in the main branch for recent builds if you look at the ffms2 thread at doom9. Specifically NTSC DV also.
http://forum.doom9.org/showpost.php?p=1733281&postcount=2122

I'm using vapoursynth compatible versions in the ffms2 thread at doom9, compiled by quot27 - maybe that is the difference?

I think it's this one if you can find it . Doom9 is down for me right now, or acting slowly .
"ffms2_r944+69-avs+vsp"

The newer versions are buggy for that branch too, that's why I stick to this one. I'll try to find the actual zip archive


EDIT:
This is not the actual 7zip original archive distributable, but I have my avisynth/plugins arranged so the original unzipped folder is accessible, so this is a re-zip of the original, with everything (including documentation, etc..)

[LMotlow]

Thanks, couldn't find that search string anywhere. Will give it a run.

[LMotlow]

The r944 version reports Y41B.

[poisondeathray]

Are we talking about the same video in post #1 ? "Salernosample.avi" ?

Did you replace/remove the old ffms2.dll ?

I can't figure it out then...another case of avisynth .dll hell ?

Every version by quot27 reports 4:1:1 planar, even the newer ones


ffmpeg itself reports 4:1:1 (yuv411p - the p is planar, not progressive)





Or you can try lsmash, which reports 4:1:1 as well

[LMotlow]

I reinstalled r944 and get the same "YUV 411" report you show above. Why that text is different now is likely something I forgot to do, but that's what I see now. But VirtualDub reports it can't open "Y41B", so I used ConvertToYV12 and VDub displays OK. That YUV-411 is 10bit or something, right? Would have to likely get into the dither plugin or something to straighten that out, but since this sample ain't the original capture it's hardly worth it.

Thanks again for the .zip. I still haven't found it via Google or Doom9 search but will keep at it later.

Whatever happened to digicube?

[poisondeathray]

YUV 411 just indicates "4:1:1" - ie. it's just the chroma subsampling . It just means Y' is 720x480 , U,V planes are 180x480 each. That's a big reason why NTSC DV has crappy color resolution. When you point resize (nearest neighbor) the chroma you get blocky color edges. Many decoders use point resize to get YUY2 or YUV 4:2:2. Point resize is very fast algorithm. They are actually upsampling the chroma to get YUY2 ie. resizing the chroma planes to 360x480 . (Sometimes you want blocky edges, but this way at least you have the option to do whatever you want, use whatever algorithm)

Anyways sorry for the diversion, back the original programming

[LMotlow]

Understood (mostly), and thanks. What a hassle. I don't even wanna think about what happened to that sample. Wish we had a piece of the original pie.

[jagabo]

Y' is 720x480 , U,V planes are 180x480 each. That's a big reason why NTSC DV has crappy color resolution

Don't forget, VHS only has about 40 lines of chroma resolution across the full frame. So capturing with 180 samples is not a loss. The real issue is how those samples get upscaled to 4:2:2 or 4:4:4 for editing or display. As was pointed out, some decoders simply repeat chroma samples (point resize) and that leads to blocky colors.

[johnmeyer]

Here's my AVISynth Info():



It sure is different from what you posted. I show audio; yours doesn't. I show "video pitch" (whatever that is) of 1440, even though the File Information for this AVS Info() script, when played in VirtualDub, shows 720x480; and it shows colorspace of YUY2.

I am very confused.

[edit]Here's my AVISynth version:



Here's the AVISynth script I used. As you can see, I used AVISource, so maybe that's the reason for the differences:

AVISource("E:\Documents\Dnload\UNPACK\Salernosample.avi")
info()

[LMotlow]

Yep, I got the same results with everything I tried except the FFMS2 r944 poisondeathray posted in #31.

[poisondeathray]

@johnmeyer - When you use AVISource(), it will use whatever system VFW DV decoder you have installed. The output will depend on how you have that configured. An easy way to determine what is currently being used is to open the AVI video natively in vdub and use file=>file information. (you have to have prefer internal decoder option disabled in the options: options => preferences => AVI => uncheckmark prefer internal video decoders)

When you use FFVideoSource() you load video only. Yuu can use the bundled FFMpegSource2() option to load both audio & video concurrently (it's just a wrapper function for FFAudioSource and FFVideoSource)

e.g. to load audio & video

FFMPEGSource2("Salernosample.avi", atrack=-1)

[johnmeyer]

@johnmeyer - When you use AVISource(), it will use whatever system VFW DV decoder you have installed. The output will depend on how you have that configured. An easy way to determine what is currently being used is to open the AVI video natively in vdub and use file=>file information. (you have to have prefer internal decoder option disabled in the options: options => preferences => AVI => uncheckmark prefer internal video decoders)

Thanks!

[jagabo]

Here's an example of a real VHS capture. The original (left) was captured as YUY2 (YUV 4:2:2) using a lossless codec (huffyuv). On the right that video was reduced to 4:1:1 then back to 4:2:2 with

ConvertToYV411().ConvertToYUY2(ChromaResample="Lanczos")

Of course, this doesn't mean that any particular DV capture device can't have issues. But 4:1:1 chroma subsampling is a very minor problem with VHS.

Here's an example with point upscaling of 4:1:1 resulting in obvious blocky artifacts:

[lordsmurf]

You can't show DV quality by simple conversion in Avisynth. It's theory.
However, practical application differs.
There's more going on than a basic (and quality) colorspace conversion.

[jagabo]

My point was that NTSC DV's chroma subsampling wasn't the cause of problems with VHS capture if you know how to deal with it. And I noted that this doesn't address other problems that may be within particular DV capture devices.

[digicube]

Yes I did use WinDV and then VirtualDub to direct stream copy a segment of the video. VCR used is Sony SLV-N88, no edit capability.

Sorry for the late reply. I didn't get email notifications for your replies this time, weird. The sample I linked was a direct stream copy from VirtualDub of the original DV video I captured using WinDV and ADVC110. I didn't use Avisynth.

I'm a layman/amateur. I can't even see the problem you guys see in the video sample because I have nothing to compare it with. I'm not gonna mess with the colors/blacks/whites because it has to be adjusted differently for different scenes. I probably just need some filters like degrain/denoise that can be applied across all VHS camcorder videos to make them look better.

Maybe jagabo's code will work with most of my VHS capture. I have to read on what the different settings do. I will also checkout johnmeyer's scripts.

ConvertToYV12(interlaced=true)
BilinearResize(width/2, height)
QTGMC(preset="medium")
dehalo_alpha(rx=3.0, ry=2.0)
MergeChroma(last, TemporalDegrain(SAD1=400, SAD2=300, sigma=16))  
TurnRight().nnedi3(dh=true).TurnLeft()
SeparateFields()
SelectEvery(4,0,3)
Weave()

[jagabo]

I'm not gonna mess with the colors/blacks/whites because it has to be adjusted differently for different scenes.

You should at least use an "average" adjustment to get overall levels within range and good contrast. ColorYUV(cont_y=-25, off_y=-6) in my original script was an attempt to do that for the clip. But you should check a wider range of shots. Learn to use Histogram() or VideoScope() to check levels.

Maybe jagabo's code will work with most of my VHS capture. I have to read on what the different settings do.

ConvertToYV12(interlaced=true)

Your source is YUY2. Some of the later filters require YV12. And the video is interlaced at this point in the processing so you need to specify that.

BilinearResize(width/2, height)
TurnRight().nnedi3(dh=true).TurnLeft()

Your video was captured without a line TBC so individual scan lines have horizontal jitter (they shift left and right a few pixels every field/frame). VHS also only has about 350x480 resolution so vertical edges are blurry. I used this pair to downscale then upscale back to the original size. This reduces the horizontal jitter and sharpens the video a bit without creating a lot of jaggy artifacts. This also gives a little noise reduction.

nnedi3() was originally developed as a deinterlacing algorithm. It doesn't introduce a lot of jaggy aliasing artifacts when it doubles the height of a field. The dh argument is used to double the frame height. But the video at this point is half width, not half height. So the 360x480 frame is rotated right by 90 degrees, the height is doubled from 480x360 to 480x720, then rotated left by 90 degrees to restore the original orientation.

Some of the other filters were applied between these two steps to speed them up. Ie, working with a 352x480 video is twice as fast as working with a 720x480 video.

QTGMC(preset="medium")

Some of the other filters require progressive video. They will screw up interlaced video. QTGMC() is the best quality (for most video) double frame rate deinterlacer available now. This converts your video from 30 interlaced frames per second (60 fields per second) to 60 progressive frames per second. QTGMC() performs a lot of other filtering including edge smoothing which helps with horizontal jitter. If you want, it also has a noise reduction option you can set with EZDenoise=1.0 -- or whatever value you want. Bigger values give more noise reduction. But high values will wash away detail and add smeary artifacts.

dehalo_alpha(rx=3.0, ry=2.0)

As noted earlier, VHS is an inherently low resolution medium. Some players try to make the video look better with a sharpening filter. Unfortunately, they usually introduce oversharpening halos. Ie, a sharp transition from dark to light will overshoot. Just before the transition there will be an extra dark undershoot, just after the transition there will be an extra bright overshoot. Most modern TVs will apply additional sharpening when they upscale, further accentuating these halos. dehalo_alpha() reduces the halos a bit. Unfortunately, it also reduces some of the real detail. There are several other settings you can play with to help prevent this, see the docs. But it's best to avoid oversharpening halos from the start. If your VHS deck has a sharpness filter -- turn it down. If your tape is a second or third generation copy the halos may be baked in.

MergeChroma(last, TemporalDegrain(SAD1=400, SAD2=300, sigma=16))

Your video doesn't have a huge amount of noise in the luma (greyscale) channel but it does have a lot of noise in the chroma (color) channels (typical of video shot under low light conditions. MergeChroma() merges the luma from the first video with the chroma from the second video. I used it to filter only the chroma channels. "last" is the result of the filter just before it, TemporalDegrain() is the filtered video.

SeparateFields()
SelectEvery(4,0,3)
Weave()

This converts the video from 60 progressive frames per second back to 30 interlaced frames per second. You should only do this if you're going back to an interlaced format like DVD.

[jagabo]

Here's some interesting information about DV encoding:

http://www.adamwilt.com/DVvsMJPEG.html

In short, some DV encoders use as little as half the bitrate they're supposed to resulting in widely varying quality.

[johnmeyer]

Here's some interesting information about DV encoding:

http://www.adamwilt.com/DVvsMJPEG.html

In short, some DV encoders use as little as half the bitrate they're supposed to resulting in widely varying quality.

I just skimmed that article. It reinforces something which a surprising number of people don't grasp: while decoding is a fixed process that always produces the same result, regardless of which implementation of the codec you use, the encoding process can vary tremendously, and yet still conform to the specifications of the standard. So, as an example, you can take the exact same video and feed it to the DV codec from Panasonic, and you will get a very different result than if you encode the same video with the DV codec from MainConcept.

These differences are not small or subtle.

I have used the Panasonic, MainConcept, Sony, Canoupus, and Microsoft DV codecs. The most widely available, for obvious reasons, is the Microsoft DV codec. Unfortunately, it is not just the worst of this list, it is absolutely horrible. I suspect that at least some of the negative posts about DV, not just in this thread, but in many others, is due to using this codec.

The same thing is true of many all other codecs. MPEG-2 implementations from different vendors produce video quality that is all over the map. The really good ones cost lots of money (thousands of dollars/euros). This is one technology where you usually do get what you pay for.

[poisondeathray]

while decoding is a fixed process that always produces the same result, regardless of which implementation of the codec you use...

In theory a decoder is supposed to give bit for bit identical output, but in practice it doesn't always happen.

You cannot always configure the decoder to yield the same output, or sometimes you cannot access the output pin directly from the decoder so other transforms may occur in the host application. For example panasonic's dv decoder always outputs RGB - a well known problem. YUV 411 vs. YUY 422 upscaling was discussed earlier. Strictly speaking, for NTSC DV, a strict decoder should output YUV 411. Some host applications upsample and convert to RGB with different algorithms, yielding different results - for example sony vegas uses point sampling to upscale the chroma (also to downscale when converting to dv fromother formats. How you downscale for ENcoding also affects the encoding output. ), quicktime does as well. It's not just dv ; other formats can have variable treatment in the decoder. Some AVC decoders can skip deblocking for example.

[johnmeyer]

Good point. I forgot about the configuration settings that some DV codecs provide in their decoders.

[digicube]

@ jagabo Thanks for the explanation, it was informative for a layman like me.

[lordsmurf]

http://www.adamwilt.com/DVvsMJPEG.html
In short, some DV encoders use as little as half the bitrate they're supposed to resulting in widely varying quality.

Be careful. Adam Wilt was the primary DV cheerleader online, and his information is not always reliable.

However, that page appear accurate, and explains some reason why DV colorspace damage occurs.

[johnmeyer]

Why all the vulgarity? I find your speech offensive. It has no place in public discourse.

[lordsmurf]

Why all the vulgarity? I find your speech offensive. It has no place in public discourse.

It wasn't really 'vulgar', but I've edited the post anyway.

[KarMa]

Why all the vulgarity? I find your speech offensive. It has no place in public discourse.

I found it funny.

[jagabo]

I do get aggravated when "Adam Wilt says" is the (attempted) reference for ending a discussion on DV.

I wasn't attempting to end the discussion. I was pointing out the claim that some DV encoders use as little as half the specified bitrate to encode the picture, and the explanation of why. So you're saying that's incorrect?

[lordsmurf]

I wasn't attempting to end the discussion. I was pointing out the claim that some DV encoders use as little as half the specified bitrate to encode the picture, and the explanation of why. So you're saying that's incorrect?

I was referencing DV discussions in general. Not you. I got off topic.

That specific page on colorspace conversion does appear correct.

[digicube]

Why am I not getting multi-thread/core CPU usage from this script?

SetMemoryMax(768)
SetMTmode(5,0)

source=AVISource().killaudio().AssumeBFF()

SetMTmode(2)

chroma=source.Cnr2("oxx",8,16,191,100,255,32,255,false)
output=MDegrain2i2(chroma,8,0,0)
return output

function MDegrain2i2(clip source, int "blksize", int "overlap", int "dct")
{
Vshift=0 
Hshift=0 
overlap=default(overlap,0) 
dct=default(dct,0)

fields=source.SeparateFields() 

super = fields.MSuper(pel=2, sharp=1)
backward_vec2 = super.MAnalyse(isb = true, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse(isb = false, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
backward_vec4 = super.MAnalyse(isb = true, delta = 4, blksize=blksize, overlap=overlap, dct=dct)
forward_vec4 = super.MAnalyse(isb = false, delta = 4, blksize=blksize, overlap=overlap, dct=dct)

MDegrain2(fields,super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400) 

Weave()
}

distributor()

[johnmeyer]

I recognize that as, more or less, some code I've posted. I get great MT speed up when I use it.

Things to check:

What version (exactly) of AVISynth are you using?

Do you really need the "distributor()" statement? I don't think it would defeat the MT, but I never use it with this script.

Finally, what version of MVTools are you using? I think that every version of MVTool2 is MT aware, but I could be wrong.

Sorry I don't have anything better to suggest.