First attempt with avisynth

[TB Player]

I'm working on a client's project capturing VHS tapes and creating DVDs. Most of the tapes have been good quality and I've been able to capture decent video and create the DVDs without much restoration/processing. But one of the tapes is in bad condition and I decided that this would be a good time to dip my toe into the AVISynth pool.

The tape seems to have faired poorly with age and there is a small amount of tape damage (wrinkles in the tape from VCRs that have tried to eat it ). Fortunately I have a JVC HR-S9911U which can play the tape without choking. The player usually gets nice results, but this video is an exception. So I did my homework and created a small avisynth script, and I wanted to check with the brain trust here to see how I'm doing. Here's the script:

AVISource("k:\Video\SHunt\SHunt_93_AuntFlo03.avi")
Trim(0,6100)
Letterbox(0,10)
PixieDust(5)
ColorYUV(levels="PC->TV")

I've posted short samples on the interwebs - the first is the AVI/huffyuv/720x480 capture with no processing. The second is after processing with my avisynth script.

Sample 1
Sample 2

I realize that the code is pretty simple but I'm really not up on all the filters, and I may be not be using the most effective filters for this cleanup, so suggestions are welcome.

[jagabo]

That tape is sorely in need of a line time base corrector to fix all the horizontal jitter. You should turn off the sharpening filter in the VCR. It's creating severe oversharpening halos. Turn off any noise reduction filters in the VCR or capture device. You need to adjust the capture devices proc amp settings to get the levels correct to alleviate the dark and bright crush. Don't capture as RGB. Use YUY2 or some other YUV 4:2:2 subsampling.

[sanlyn]

Hmm...yes, jagabo has some good advice: you need a line tbc, either with a VCR that has one built-in or using a pass-thru device such as one of several DVD recorders suggested in other threads. But just a quick note ....

The original cap is probably YUV (YUY2): the script opens the avi directly but ColorYUV won't run in RGB -- unless the O.P. previously changed colorspaces before running the posted script. It appears that the sample was cut in VirtualDub and saved in full processing mode, which made the conversion to RGB (?).

By using Letterbox(), the frame size is 472 vertical, which could be a problem. Better to use the code below to crop off the noise at the bottom and center the image vertically, while maintaining 480 pixel height:

Crop (0,0,0,-8).AddBorders(0,4,0,4)

I'm guessing that the tape player doesn't have a sharpener. But that's a guess. Many VCR's have image "enhancements" that can't be turned off. The tape is playing or was previously played on a machine with worn heads. Edges look very ragged, line timing aside. What player was used?

The use of Levels("PC->TV") keeps luma within 16-235 but clips darks and brights. Chroma remains outside that range.

[TB Player]

That tape is sorely in need of a line time base corrector to fix all the horizontal jitter. You should turn off the sharpening filter in the VCR. It's creating severe oversharpening halos. Turn off any noise reduction filters in the VCR or capture device.

The only filtering option this deck has is a switch for "TBC/NR". It was off during this capture.

You need to adjust the capture devices proc amp settings to get the levels correct to alleviate the dark and bright crush.

I know how to access these settings, but are there guidelines to making this kind of adjustment, or is this just kind of a trial and error thing, "adjust/look at result/re-adjust if needed"?

Don't capture as RGB. Use YUY2 or some other YUV 4:2:2 subsampling.

The original video was captured YUY2 using huffyuv. The samples were cut in VD, as sanlyn surmised, and if they are RGB it was just because of my inexperience.

Hmm...yes, jagabo has some good advice: you need a line tbc, either with a VCR that has one built-in or using a pass-thru device such as one of several DVD recorders suggested in other threads.

My JVC deck has a built-in TCB/NR option but I disabled it for this capture - I did an A/B comparison of captures with/without the TCB and the video seemed a small bit sharper without it. But with the poor quality of this video I'm wondering if I should enable the TBC and live with that small sharpness hit.

The original cap is probably YUV (YUY2): the script opens the avi directly but ColorYUV won't run in RGB -- unless the O.P. previously changed colorspaces before running the posted script. It appears that the sample was cut in
VirtualDub and saved in full processing mode, which made the conversion to RGB (?).

As I mentioned above, yes, the orignal capture was YUV2 with VDub, and I used VDub to create the samples. If the samples came out RGB it was because I didn't realize that had happened (or intended it to happen). The script was run on the original YUV capture, although when I added the ColorYUV filter I didn't notice a difference in the output.

By using Letterbox(), the frame size is 472 vertical, which could be a problem. Better to use the code below to crop off the noise at the bottom and center the image vertically, while maintaining 480 pixel height:

Crop (0,0,0,-8).AddBorders(0,4,0,4)

I'm guessing that the tape player doesn't have a sharpener. But that's a guess. Many VCR's have image "enhancements" that can't be turned off. The tape is playing or was previously played on a machine with worn heads. Edges look very ragged, line timing aside. What player was used?

The player is the JVC I mentioned in my first post. Other than the TBC/NR switch there are no other filter options, although I haven't located the user's manual so I haven't determined what built-in "features" the deck has. As far as the condition of the tape, it came to me the way it is - I'm sure it was played a few times on a home-quality VCR and the tape was wrinkled when I received it. My JVC deck usually plays well with tapes in good condition.

While researching avisynth scripts I was wondering what the difference was between Crop() and Letterbox(), so from what you wrote it seems like I should be using Crop(). I'll give that a try.

The use of Levels("PC->TV") keeps luma within 16-235 but clips darks and brights. Chroma remains outside that range.

So should I remove the Levels() filter and use a chroma filter, or just add an appropriate chroma filter?

[sanlyn]

The use of ColorYUV depends on the video. If the contrast range in YUV is a bit stretched, you vcan use something like ColorYUV(cont_y=-20) to calm things a bit. A negative contrast value for the Y channel helps keep the darkest and brightest elements safe from clipping when you plan to work in RGB. You can sue Levels in the way it was used, if you want. Clippinmg isn't bad here, but you can see the difference in the bright end via histograms.

My experience with TBC-equipped JVC's taught me early that tracking damaged tape is usually not the best thing you can do with those players. It depends on the player. Earlier JVC's from the mid-to-late 1990's were heftier, more robust units with better tracking to begin with. I ended up tracking bad tapes with Panasonics from 1996-98. By 2000, most VCR's were apparently made from recycled tin cans and Tupperware, regardless of the brand name. It comes down to doing the best you can with what you have.

[manono]

I know how to access these settings, but are there guidelines to making this kind of adjustment, or is this just kind of a trial and error thing, "adjust/look at result/re-adjust if needed"?

I make a bunch of 'test' caps of 30 seconds, a minute, whatever, maybe from different parts of the tape. Then put on AviSynth's Histogram filter, or this:

ColorYUV(Analyze=True)
Limiter(Show="Luma")

Study the results and make adjustments until you get it the way you want before making the 'real' capture. Different scenes might show different results. You just want them within reasonable limits so you won't lose the light and dark detail so you can get good results when adjusting the levels and luma later on.

As much as some around here like the JVCs, having the DNR tied to the line TBC is a deal killer for me for the reason you noticed - the noise removal kills a lot of the detail. I don't see how you have much choice though, short of buying a different VCR or a DVD recorder to be used in pass-through for its TBC instead.

[Evil_Burrito]

Wow, that footage needs some serious repair. I have some video that has similar jitter (although yours is more extreme). I have tried several times, but I haven't found any solutions. If you figure it out, I'm sure you would be helping many people.

What I can recommend (that is, if you can repair the heavy jitter) is a DeRainbow filter like LUTDeRainbow or cnr2 (chroma noise reducer). Also, a deinterlacer (assuming you don't want interlaced), maybe with an extra filter to remove teeth/combing, like decomb or tcomb (qtgmc is a good deinterlacer with many extra post processing features). Lastly, I think UtVideo Codec is a better choice for the lossless codec.

btw, if I am not in a rush, I will add Gradfun3() at the end of a script. It is a high quality dithering/debanding filter.

[TB Player]

The use of ColorYUV depends on the video. If the contrast range in YUV is a bit stretched, you vcan use something like ColorYUV(cont_y=-20) to calm things a bit. A negative contrast value for the Y channel helps keep the darkest and brightest elements safe from clipping when you plan to work in RGB. You can sue Levels in the way it was used, if you want. Clippinmg isn't bad here, but you can see the difference in the bright end via histograms.

Thanks for the advice.

My experience with TBC-equipped JVC's taught me early that tracking damaged tape is usually not the best thing you can do with those players. It depends on the player. Earlier JVC's from the mid-to-late 1990's were heftier, more robust units with better tracking to begin with. I ended up tracking bad tapes with Panasonics from 1996-98. By 2000, most VCR's were apparently made from recycled tin cans and Tupperware, regardless of the brand name. It comes down to doing the best you can with what you have.

OK, I understand what you mean, so taking it a step further, given that I only have the JVC and a few cheapy home VCRs, it sounds like I shouldn't bother using the TBC/NR function. Or do you feel that, with this deck, it wouldn't make any difference?




Sent using more processing power than NASA used to go to the moon.

[TB Player]

What I can recommend (that is, if you can repair the heavy jitter) is a DeRainbow filter like LUTDeRainbow or cnr2 (chroma noise reducer). Also, a deinterlacer (assuming you don't want interlaced), maybe with an extra filter to remove teeth/combing, like decomb or tcomb (qtgmc is a good deinterlacer with many extra post processing features). Lastly, I think UtVideo Codec is a better choice for the lossless codec.

Thanks for the tips! I'm not familiar with utvideo ... I'm capturing AVIs for editing in Premiere Pro so I'll look into utvideo to see if it fits my needs. Also, I do want the video interlaced as the destination is NTSC DVDs.

btw, if I am not in a rush, I will add Gradfun3() at the end of a script. It is a high quality dithering/debanding filter.

I'm not in a real hurry, but what would dithering/disbanding do to my video?



Sent using more processing power than NASA used to go to the moon.

[Evil_Burrito]

I understand your point about the interlace, but I think you will have better looking results if you deinterlace. Progressive is the way to go, interlaced content is practically dead . Even if you (for some odd reason) need re-interlace the footage, I would bet the new version still looks better. Also, if you first do a deinterlace pass, you will have a greater selection of compatible avisynth filters to test and play with before you encode the final version.

I use avisynth very regularly and avspmod has become an invaluable tool for writing scripts, previewing/tweaking filters, and doing test encodes (it has a vfw (video-for-windows) encoder utility and a x264.exe cli (command-line-interface) launcher).

Dithering: when using the Gradfun3 default values, basically you can think of it as refining and slightly repairing (debanding) gradients. To the untrained eye, you will likely not see a difference at 100% zoom. But if you zoom in about 300% or more to a specific area of a frame that has solid color/gradients and then make a comparison of before and after you will see the difference in quality.

There are a couple other different filters/scripts that dither/deband, but they have a larger more obvious effect on the output (which is not usually the desired effect). You could do further research on the doom9 forums and read each filters help files, but if you don't need to know all their nuances and how they work, just stick with default Gradfun3 for safe and high quality results.

[sanlyn]

I understand your point about the interlace, but I think you will have better looking results if you deinterlace. Progressive is the way to go, interlaced content is practically dead . Even if you (for some odd reason) need re-interlace the footage, I would bet the new version still looks better. Also, if you first do a deinterlace pass, you will have a greater selection of compatible avisynth filters to test and play with before you encode the final version.

I use avisynth very regularly and avspmod has become an invaluable tool for writing scripts, previewing/tweaking filters, and doing test encodes (it has a vfw (video-for-windows) encoder utility and a x264.exe cli (command-line-interface) launcher).

Dithering: when using the Gradfun3 default values, basically you can think of it as refining and slightly repairing (debanding) gradients. To the untrained eye, you will likely not see a difference at 100% zoom. But if you zoom in about 300% or more to a specific area of a frame that has solid color/gradients and then make a comparison of before and after you will see the difference in quality.

There are a couple other different filters/scripts that dither/deband, but they have a larger more obvious effect on the output (which is not usually the desired effect). You could do further research on the doom9 forums and read each filters help files, but if you don't need to know all their nuances and how they work, just stick with default Gradfun3 for safe and high quality results.

Can you post for us a demo of work from the O.P.'s sample that demonstrates how GradFun3 would be beneficial as regards banding?

Whether a video looks "better" as interlaced or deinterlaced is a matter for individual videos. Most people need a player and TV that can do a cleaner job of handling all of the planet's videos and broadcasts that are interlaced or telecined.

Played as pure progressive, the sample 1 video looks no better than interlaced. Deinterlacing and getting back to 29.976 fps by discarding frames would be kinda tricky for a vid that's as soft and low-density as this. There's hardly any detail here, not one clean edge or straight line, and there's motion smear. And dot crawl, thanks to composite cable. The O.P. might try a capture with TBC turned on, but that won't stop the edge streaking caused by playing tape with what looks like bad heads or a seriously ill gain circuit. It can be made to look somewhat cleaner and calmed a bit, aside from a trip thru Industrial Light & Magic.

[2Bdecided]

Progressive is the way to go, interlaced content is practically dead .

He is creating DVDs. Back here on planet earth, DVDs of home movies* are (almost) always interlaced.

The only exception is if they were deinterlaced by someone who didn't know what they were doing - because doing so loses half their temporal resolution. DVDs cannot store 50p or 60p, only 25p and 30p (plus lower rates, like 24p, via some clever fiddling) - none of which maintain the temporal resolution of 50i or 60i. Luckily DVDs can store 50i and 60i as they are - interlaced.

You're right that many AVIsynth filters require you to bob-deinterlace, or at least separate the fields - and you're right that many of these filters will make certain videos looks better - but the final DVD will be interlaced. Bob-deinterlace if you need to, not as a default option.


* - I haven't downloaded the sample, so I've no idea what it is

Cheers,
David.

[jagabo]

The OP's video is 30i (aka 60i). It looks like a second generation VHS tape. I would at least try using the VHS decks TBC to get rid of the horizontal jitter. Sharpness should not be a consideration at this point.

[TB Player]

* - I haven't downloaded the sample, so I've no idea what it is

Your assumption was correct - these are home movies.

The OP's video is 30i (aka 60i). It looks like a second generation VHS tape.

That was my thought as well - this tape looked like it was 2nd generation. Most of the other tapes I received from this client were obviously the actual tapes used in her video camera - this one is the worst of the lot.


After reading through all of the comments here I decided to go back to the tape and create some comparisons. First of all, there have been comments that my JVC deck is not up to par or may have damaged heads, so I captured from one of my own home videos to demonstrate the usual quality I get from captures. Example A is a capture using the composite outputs of my JVC deck into my ATI Rage Fury 128 card, then captured using VDub set to 720x480 with huffyuv compression. Hopefully this should give you some idea of how my JVC deck is performing. (Regarding the ATI card, the only s-video option is an output port, so capturing the composite signal from the JVC is my only option.)

Example_A


Then I re-capped video from the tape we've been discussing. Sample 3 is the same settings as my home video (above) with the TBC/NR engaged. Sample 4 is without TBC/NR. Basically, an A/B comparison switching the TBC/NR switch on/off.

Sample 3
Sample 4

I'm interested to know what you guys see in the two samples.

EDIT: I've corrected Sample 3 and Sample 4 - they are now unprocessed, captured with huffyuv at 720x480. If MediaInfo is telling you that the vids are RGB, it's lying to you!

[sanlyn]

What can be suggested with the last 3 samples is limited. They've all been converted to RGB (brights blown away) and cropped to 720x472. Example_A has visible combing artifacts. It might be more revealing to see a piece of the captures before they were modified.

[jagabo]

I noticed the color difference int the top/bottom fields too. That can probably taken care of with a little filtering.

The TBC/NR filter is reducing the jitter a bit in sample3. And the NR isn't so heavy that it's ruining the picture. I'd probably go ahead and use it.

[TB Player]

What can be suggested with the last 3 samples is limited. They've all been converted to RGB (brights blown away) and cropped to 720x472. Example_A has visible combing artifacts. Also has cyan color cast in the even frames, heavy magenta cast in odd frames. It might be more revealing to see a piece of the captures before they were modified.

Well, that's what I thought I had posted.

The samples came from longer captures - all I did was trim them in VDub using Direct Stream Copy, which I *thought* retained the compression/color space. Or is there a better app to use for trimming without processing?

[TB Player]

I noticed the color difference int the top/bottom fields too. That can probably taken care of with a little filtering.

The TBC/NR filter is reducing the jitter a bit in sample3. And the NR isn't so heavy that it's ruining the picture. I'd probably go ahead and use it.

Thanks.

[TB Player]

OK, for those who are interested, I uploaded new versions of samples 3 & 4. The new samples are the direct capture files from the JVC, untrimmed, with VDub/huffyuv/720x480.

[jagabo]

I'm not sure what the deal is with the new sample3. MediaInfo shows HuffYUV in RGB mode. But it comes out of the HuffYUV decoder as YUY2.

[sanlyn]

All three samples are huffyuv RGB. I was about to say that the TBC/on sample looked somewhat cleaner but jagabo bat me to it (again).

Why are all your samples 720x472 ? What happened to the usual 480 pixel height?

[jagabo]

I just checked: MediaInfo always seems to show RGB for HuffYUV, even if the source was YUY2 and it's encoded as YUY2. In any case, the YUY2 video that comes out of these files includes super darks and super brights so I don't think there's any problem with colorspace conversions.

I don't know why they're only 472 lines high.

[sanlyn]

Yep. Avisynth info() sez YUY2. Each day, I get a little more leary of MediaInfo.

All of the O.P.'s posts in this thread are 720x472.

[TB Player]

Thanks to all for the input/responses.

I don't know why the samples are 720x472. VDub was set at 720x480 for all captures. My best guess, based on what I've read, is that my ATI card captures internally at that size, but that doesn't explain why the capture wasn't re-sized in VD.

I haven't had a chance to closely inspect the samples, but I have suspected that I may need to enable TBC/NR and live with the artifacts just to get a handle on the jittery video. As jagabo implied, sharpness may not be an option.

[Evil_Burrito]

I don't have time right now to make a complete response to sanlyn and 2Bdecided.

Attached are 2 screens I made from frame 13 and 22 using video from first post.

The columns are: Processed-Unprocessed-Difference - From a quick avisynth script I wrote to demonstrate the filters I mentioned (settings left default).

backup images link

https://picasaweb.google.com/109966249066847502296/AvisynthHomeVideo?authuser=0&authkey=Gv1sRgCKDor-D1iJvBiwE&feat=directlink

[TB Player]

Yep. Avisynth info() sez YUY2. Each day, I get a little more leary of MediaInfo.

All of the O.P.'s posts in this thread are 720x472.

Yes, and I've wondered why my caps came out this size since I always cap in VDub at 720x480. So I did a little testing using Lagarith in VDub and the cap still came out 720x472. Then I captured uncompressed and the cap still came out 720x472. I also tried capping with Xvid and it still came out 720x472! Then I capped using the ATI MMC and the video came out 720x480, so I tried another cap with vvcr and that also came out 720x480. So I'm guessing that the combination of my older ATI card with VDub is somehow causing the unwanted video sizes.

What is/are the possible problem/s with using a video that is not standard size?

[jagabo]

Then I captured uncompressed and the cap still came out 720x472.

Did you specify the frame size before capturing? Video -> Set Custom Format.

[TB Player]

Then I captured uncompressed and the cap still came out 720x472.

Did you specify the frame size before capturing? Video -> Set Custom Format.

Yes, that's what I meant by "since I always cap in VDub at 720x480".

[TB Player]

All of the O.P.'s posts in this thread are 720x472.

I deleted all of the files in my computer's VDub folder and extracted new files into it - VDub is now capturing at 720x480. I assume that there was something askew in the config files, which got replaced when I installed new files.

I corrected the samples in post #14 - they should now be unprocessed huffyuv 720x480.

By using Letterbox(), the frame size is 472 vertical, which could be a problem. Better to use the code below to crop off the noise at the bottom and center the image vertically, while maintaining 480 pixel height:

Crop (0,0,0,-8).AddBorders(0,4,0,4)

I tested both Letterbox and Crop. With Crop(0,0,0,-16), Crop reduces a 480 video to 472. Letterbox does not shrink the vertical size, which seems like a better solution. I thought it was a bad thing to shrink the size to non-standard?

[sanlyn]

To restore frame size after using Crop(), use AddBorders(). You see in the code quoted above that AddBorders was used after Crop. Crop was used in that way to center the image vertically. If you use Letterbox and don't want to mask off top pixels, use something like Letterbox(0,8). You can also mask off head switching noise at the bottom with the BorderControl filter in VirtualDub. On playback, however, the image will look as if it's a few pixels above center in the display. If your TV is using its default overscan setting, you might miss a few pixels at the top. But with 8 pixels it would hardly matter.