Need some help with simple script to process VHS cap

[bigmick]

Hi Friends,

I've been given the dubious honour of capturing the family home movies off the original Video 8 tapes or VHS (dubbed off video 8). After many hours researching online I think I've got the capturing part all sorted and am happy with the results. I'm capturing the interlaced PAL material at 720x576 and encoding with HuffyUV. It has a mono audio track, but dealing with it is for another day.

I've spent the last week or so reading up on post processing. I've settled on using Avisynth and opening the avs directly into CCE. I'll cut the capture waste and perform basic splicing in the avs and then more fine editing once I've encoded to mpeg as I've got better tools to do it there and it's easier (quicker).

Where I'd love some help is putting together a basic Avisynth to process the video.

Here's what I'm looking to achieve:
- Letterbox to remove head switching noise
- Correct the capture aspect ratio (if it can be done without complicating things or adding too much processing time)
- *Minimal* denoise to help the mpeg encoder - i'd rather encode to a higher bitrate and store on more dvds than start using aggressive filters and introduce unwanted effects. I'd like to get at least 2 hours on a single-layer DVD though.
- I've done enough searching to appreciate the complexity involved in filtering if your aim is to improve the output quality-there are so many filters out there and so many settings-unfortunately I really don't have time to get up to speed on all this stuff, so unless someone can recommend some filter settings which will always benefit VHS capture, I'm just going to go with minimal noise filtering I think.

Here's the basis for a script from what I've been able to piece together so far:

----------

# Load the input files
AVISource("somevideo.avi")
# Do my trimming and splice addition cap files here

# Remove the head switching noise - use multiple of 16 again to help mpeg encoder
# I've figured I need about 14 off the bottom anyway
LetterBox(16,16)

# Denoise - as we are applying a temporal filter (works across frames)
# we need to split our interlaced frames up
# (or is it because of the spatial aspects of the filter??) I've found references to both.
SeparateFields()
even = SelectEven(last).PixieDust(5)
odd = SelectOdd(last).PixieDust(5)
Interleave(even, odd)
# I don't think this is going to work anyway - see comments below.

# Correct aspect ratio - I've figured out my card has an active capture window of 706 pixels
# I'm not exactly sure which ones they are but will assume it is centered.
# The capture driver has scaled these 706 out to 720. Scale it back then add black borders.

# Perform the resize before we recombine the fields-is this best???
# Note in this case that the height is divided by two, since we are resizing
# the fields instead of the frames
LanczosResize(706, 288)

# Join the interlaced fields back together into single frames
Weave()

# Add the black bars on each side to get back to the 720 resolution.
# To give us black blocks of 16 we will have to crop a bit more off
Crop( 9,0,-9,-0)
AddBorders(16, 0, 16, 0)

# Correct the colour levels if they were distorted by the capture card
# is there an easy test to determine if my capture card is susceptible to this
# (or does anyone know - ATi Radeon 9600XT)??
ColorYUV(levels="PC->TV")

# I've also seen references to chroma shift, deshaking, undot, etc - is there anything fundamental
# (a must have) I'm missing for processing a VHS cap?

# Somewhere I have to ensure I'm feeding CCE with the field order it expects
# Check/switch it here or in CCE settings


Appart from wondering if I have things in the best order and am doing the right processing with interlaced frames as opposed to fields separated, my main problem is with the noise filtering - I believe the above wont work as you cant call PixieDust more than once and I understand it is deprecated now anyway, but have no idea what the new equivalent is. Also I only want mild filtering so the (5) might be too strong?? Any help in this area would be really appreciated.

I'm sure someone is going to ask, but I can't really post up any representative samples as there is a lot of variation - we've had different cameras over the years, the age and condition of the tape varies (some tapes date back to the mid 80's), subject matter, person taking video, some is off VHS dub, some off the super 8 etc etc. I'm really just looking for a one size fits all sort of script that is going to achieve reasonable results - I know to get great results would take hours of testing and tweaking on each individual capture file, but I'm not really prepared to put in that sort of time at this stage.

Thanks
Mick

[neuron2]

To avoid the multi pixiedust's and avoid your suboptimal interlaced resizing, you should use a good bobber on the video first. Then do your filtering. At the end reinterlace it:

sbdeint # bobber that I like
# your processing here
# reinterlace as TFF
separatefields()
selectevery(4,0,3)
weave()

[2Bdecided]

IMO, even 8Mbps isn't enough to "preserve" all VHS noise without it introducing some blocking artefacts somewhere, so hoping to keep most of the noise while encoding 2 hours per disc is unrealistic (i.e. it will give visible coding artefacts, and won't keep the noise). YMMV.

Not sure about the aspect ratio error of your capturing device - PC capture cards aren't my thing. If you're sure that you're starting with 706 pixels -worth spread out over 720, then the easiest thing is to resize to 704x576 (crop some pixels first if you must) and encode that - there's no requirement for 720 on DVD; 704 is equally valid, and more consistently handled.

Do you have head switching noise at the top too? You're blanking top and bottom, which is probably unnecessary.

If you're working in YUV throughout, I can't imagine ColorYUV(levels="PC->TV") is needed. A simple histogram() or histogram(mode="levels") will show you whether you have blacker-than-blacks, whiter-than-whites (quite common on camcorders), or whether black is where it should be at 16, or whether black is higher than it should be (e.g. 32-ish). See here:

http://avisynth.org/mediawiki/Histogram

The shaded regions at the left and right of the graphs mark the <16 and >235 regions which should be avoided.

Finally, each generation of VHS shifts the chroma down by 1 line per field (2 lines per frame). Shift it back up again, using something like...

# Fix (S-)VHS chroma shift
Vshift=2 # determine experimentally
Hshift=2 # 2 lines per bobbed-field per tape generation (PAL); original=2; copy=4 etc
mergechroma(last.crop(Hshift,Vshift,0,0).addborders(0,0,Hshift,Vshift))

from here:
http://forum.doom9.org/showthread.php?t=136373

Hope this helps.

Cheers,
David.

[bigmick]

Hi Guys,

Thanks very much for the tips! All much appreciated.

I originally tried capturing with the hardware mpeg encoder on my tuner card and got terrible results - lots of blocking artifacts even in VBR mode at a resonably high bitrate - i put this down to it a combination of its quality and the fact it has to do a single pass, but your post Dave made me realise it's life was probably made hard by the noisy source material. I'm just using a standard VCR feeding through a TBC box so don't have any filtering. Anyway, point being the whole reason I'm going this avisynth road is to avoid this blocking so will definately go with some noise filtering then, will try what neuron2 suggests, temporarily deinterlacing the clip for processing.

Is PixieDust still a good filter to use or is there something better now?

Dave, the 704 is also a good point - didn't realise that. I went through the exercise of generating a test dvd and capturing it to calculate the capture window, hopefully I did it right. Will have a look into the other tips you mention too.

Thanks again guys,
Mick

[smok3]

speedwise (and if you have compatible GPU), you may try FFT3DGPU.

example, with some big values here:

FFT3DGPU(sigma=4, sharpen=0.5, plane=0, mode=1, bt=4) # luma
FFT3DGPU(sigma=10, plane=3, mode=1, bt=4) # chroma

[ankurs]

get us a sample and let us script and post results :)

[bigmick]

get us a sample and let us script and post results :)
Hi I'd love to post a sample but two problems - what I said upfront about the variation in the different clips and I just tried to cut a small sample (1.5 minutes) and it's almost 900Mb! What should I do? How much do you need?

My thoughts on the bulk of the footage:

it's obvious pretty low quality
the colours are a bit washed out in general, although odd bright colours (such as pinks, reds, oranges etc) at times come through strongly
there's noticable flicker
probably lots of other issues to a trained eye


wrt a denoising filter, i've been looking into smok3's suggestion of FFT3DGPU - I like the promise of speed and my graphics card is compatible - but honestly there are so many options on the denoiser front (both filters and parameters) it's very hard for a newbie to get a feel for what to use. I've come across posts suggesting pre-written scripts like MCTemporalDenoise and MC_Spuds might be the go for newbies like me. I see that MCTemporalDenoise has an option to use the GPU but MC_Spuds doesn't seem to. Not sure what the relative merits of each are and how suitable they are vs a single filter like FFT3DGPU in my situation - can anyone help steer me in the right direction here? Basically I'm looking for a relatively fast denoiser with the objective of improving compressibilty without introducing any issues/artifacts or removing a noticable amount of the pecious little detail left in my crappy source material.

@neuron2:
What effect does deinterlacing and reinterlacing have on the material - (happy to take a link to previous discussion if that's easiest) I remember skimming a good discussion on this when looking for something else, but of course I can't find it now I want it. Keen to know whether the deinterlaced portion of the material is eventually discarded and only used to help out the filters in the interim or whether some of this makes it's way into the final result (prob what I'm really asking is does it matter greatly what bobber I use for this??) Also I think MCTemporalDenoise and MC_Spuds might have options to handle interlaced material, if I use one of them would I be better feeding them the interlaced material or doing what you suggest? Maybe they are just doing something like this internally anyway?

@2Bdecided
I want to say thanks again for your particularly helpful post and the link to your script. It's a good template for me. A couple of questions about it:

Can you explain the bit about warping the chroma?
Why re-add noise rather than using a lower noise filter threshold to start with??
If I'm encoding to DVD format should I leave in YV12?


Thanks,
Mick

[2Bdecided]

1. warpsharp is just a kind of sharpening, often applied to anime. As used in that script (thanks to Didee, I think) it looks at the edges in the luma, and tries to sharpen the chroma at/to those edges. It works, but isn't perfect - occasionally it can make things worse by making tiny patches of colour get lost in the surrounding colour. However, it can give amazingly clean sharp chroma from messy sources. The eye isn't so sensitive to chroma (though less noise is nice) but it saves encoders preserving a lot of junk.
2. because I just blindly used mcspuds at its default settings. It's not just a stupid approach though - sometimes it's exactly what you want - a very clean result, with a tiny proportion of the original noise added back; it can look different from a denoiser that's been backed-off a bit. YMMV.
3. Yes (depending on your MPEG encoder).


If you bob in a way that preserves the original fields, and select the correct fields to keep when re-interlacing, then the "added" stuff is only used to give the denoiser more to work with. Of course if you take a dumb bob, and then denoise it either temporally or spatially or both, you'll smooth the blured interpolated lines into the "real" lines, and the picture will look softer. That said, IMO the other deinterlacers are either very slow and/or won't help as much as you'd expect (if at all!) with noisy material.

I don't know if you tried it, but mc_spuds is slow.

Cheers,
David.

[bigmick]

I've decided I'm going to do some tests with MCTemporalDenoise and see how that goes for me.

So, I've opened one of my captures up in VirtualDub using the following script in order to confirm the field order, but I've noticed something odd:


AVISource("test5.avi")
AssumeTFF()
SeparateFields()


By switching between AssumeTFF and AssumeBFF I can definately say it's a TFF clip. However the odd frame is still out of order. What would caues this?? There is also a lot of "wobble" back and forward between the two fields which you can see as you single step through the separated clip. It looks really horrible actually - distorts and stuff...

I've cut a very small clip so you can see what I mean (it's still about 40Mb - sorry not sure if there's a way people normally squash these things down - it's encoded with HuffyUV 2.1.1 CCE SP 0.2.5). Separate the fields and watch the boy's legs walking down the stairs to see the out of order frames. Then the end of the clip the purple flowers show the distortion/wobble.

http://www.mediafire.com/file/fky2njmmzfz/test5.avi

This was my capture setup:
Video 8 camcorder (composite) -> CTB-100 (TBC) (s-video) -> ATi Radeon 9600 XT -> VirtualDub

Any ideas what's gone wrong and what I can do to clean the material up now (if I need to do anything)??

@2BDecided - thanks for your reply! I'm learning a lot here.

Thanks

[2Bdecided]

This is probably bad news if you've done all the capturing, but either the TBC or the capture card is confused by what's on the tape, and is dropping the content by 1 line per frame occasionally. Obviously this reverses the field order, and hence reverses the motion - but just for that single frame. You can see the geometry of the picture distort (especially at the top) just before the problem - this is probably a tape glitch, partially corrected by the TBC, and maybe it's the glitch that causes the confusion.

I realise you want to use a TBC, but just for an experiment, try capturing the same section several times - both with and without the TBC in-loop, and see (a) if it's consistent, and (b) if it ever happens without the TBC.

I don't know what you can do about it post-capture. Maybe someone else has some ideas?

The closest thing I've experienced myself is on an old PAL Dazzle Hollywood DV Bridge which would reverse the field order at random - it was a useless piece of junk really, whereas your capture device is decent.

You could try asking at videohelp.com - their forum has more people contributing to the capture section than doom9.

Cheers,
David.

[bigmick]

Yeah, this isn't really what I want to hear - when I saw it I was hoping it didn't mean my TBC was playing up - it's also the first bit I've looked at so hoping i've just picked a bad bit rather than it being through everything. I'll do a test without the TBC as you suggest, but I've already captured everything :( nothing's easy eh....

Thanks for your continued help David.

Cheers

[bigmick]

I'm finally getting back to this - only get time to work on projects like this in the holidays.

In case anyone comes across this and is interested, I've followed the advice from 2Bdecided and posted over on VideoHelp about the out of order fields: http://forum.videohelp.com/topic378111.html