First VHS capture, advice on levels?
 

After much reading on this forum and setting up a basic workflow (to get me started), I have begun capturing some home recordings from my PAL VHS tapes. Alternative/better equipment may come in time, but for the moment the below is my setup.

My workflow is Mitsubishi VCR > Composite > Panasonic ES10 (DNR Off, Comb Filter On) > S-Video > Diamond VC500 > VirtualDub2.

I capture as lossless AVI using Lagarith, YUY2, PAL_I, 768x576. Before capturing I temporarily Crop the black borders and bottom head switching noise, then adjust the Brightness and Contrast in Levels whilst looking at the Histogram to keep luma within 16-235. I reset the Cropping to 0 and turn off audio playback during capture. I will keep my lossless AVI files for archive.

I then use AviSynth+ to deinterlace the file with QTGMC (Preset=Faster), Resize to 720x540 for 4:3 aspect ratio then Crop and add Borders.

My final viewing will be playback from a HTPC connected (via HDMI) to my Smart TV, although I will also be sharing files with family who might play the files on a computer. My final delivery format is H.264 created using command line FFmpeg (calling in my AviSynth file).

Attached is my first capture. Have I correctly set Levels for this clip?

The vertical resolution is quantized, so resizing from 576 to 540 will reduce sharpness slightly. Then to fix it you have to add sharpening, which adds halos. So it's best to avoid resizing.

I don't have Lagarith installed so I can't check the levels.

Oops, my error...I meant that I capture at 720x576 (not 768x576). Then resize to 720x540.

From reading a number of posts about resizing to correct the aspect ratio for square pixel displays and to ensure a playback display aspect ratio of 4:3, I had understood that the 720x576 capture should be resized to either:-
A) 768x576 (not preferred as it scales the video up); or
B) 720x540 (preferred)

Have I understood the above correctly?

I think QTGMC includes some sharpening, but I have tried to avoid any further sharpening of VHS to avoid causing halos.

This is my AviSynth script:-

SetFilterMTMode("QTGMC", 2)
FFmpegSource2("2021.12.31c - VHSClip.avi", atrack=1)
ConvertToYUY2(interlaced=true)
AssumeTFF()
QTGMC(Preset="Faster", Edithreads=4)
BilinearResize(720,540)
Crop(12,0,-12,-12)
AddBorders(12,4,12,8)
Prefetch(14)

If you use a container format that has native support for aspect ratio settings, you shouldn't have to do any scaling at all.

Since you're using FFMpeg, you can add to the command line and players will understand it if your container is MP4 or MKV.

C) 720x576 (best)

traal is right, there is no need at all to do any (loss) resizing. Captured frame is 720x576 and will display at proper 768x576 dimension when DAR (Display Aspect Ratio) is set to 4:3 (576x4/3=768).
The unique case where you can crop (not resize) to 540 in theory is when the active pixels in the vertical directions are effectively 540, but I have never seen that in PAL.

To be more accurate, you could crop (not resize) the 720x576 frame to 704x576 before any further processing, because the ITU-R BT.601-4 (formerly "CCIR-601" or "Rec.601" spefication for Analog SD is 702(704)x576 pixel inside the 720x576 frame, the rest should be black.

Your levels are ok, however I wuold have not shrunk the high Y level to 235, because your card is able to capture up to 254. By doing that with the mediocre internal procamp you are introducing artifacts, while if you operate in AviSynth you can get a better shrink (or do not do any shrink at all).
It is ok to use the procamp to shrink at Y=16, because your card cannot capture levels < 16, so either you clip them or you use the procamp to stay inside 16-2XX range; second suffers or previous limitations, but is better.

Thank you for the advice. Essentially it is better to correct the aspect ratio when encoding then, rather than resizing in AviSynth.

I will crop 16 pixels total off the left/right. Should I then add black borders to maintain the frame size at 720x576?

My basic script is now:-

SetFilterMTMode("QTGMC", 2)
FFmpegSource2("VHSclip.avi", atrack=1)
ConvertToYUY2(interlaced=true)
AssumeTFF()
QTGMC(Preset="Faster", Edithreads=4)
Crop(8,0,-8,-12)
AddBorders(8,4,8,8)
Prefetch(14) )

Did I call Crop and AddBorders at the correct place in the script?

Also, out of interest, how can you establish that the Diamond VC500 USB can capture Y=16-254 ?

All the VC500's I've used capture the full 0-254 at least (conexant ones, no idea about the ancient early ones with Trident chipsets). Though,I have noticed that they sometimes start clipping at y=16 after changing TV standards (only lasts until you reboot or re-plug the card.)

Yes mine is a Conexant one. That is interesting it can capture at 0-254. But how do you check that - from a spec sheet or in software?

Actually there is no ascpect ratio to correct. Captured 720x576 is "supposed" to be 4:3 DAR, but the info is missing because the avi container for lossless captures does not contain that flag (if you open the file in VirtualDub or VLC without setting 4:3 aspect ratio the image is shrunk in horizontal dimension).
You can add the dar info when encoding with ffmpeg as suggested by traal, or, if you do not want to encode, you can add the dar with:
This last is more a theory than a good practice, because you will end up with a new additional very large file!

Yes. If you plan an upscale, i.e. Youtube or whatever, or if you plan a further processing, i.e. encode you can add black borders to create a 704x576 frame instead. Not a very big difference when watching in standard conditions, but more adeherent to specifications.

I would use AviSource() instead of FFmpegSource2(), because some of its versions have not accurate frame positioning if you need to work at frame level.
The conversion to YUY2 is redondant then.
The "faster" preset or defaults setting in QTGMC tends to give a plastic look and oversharpen, but that really depends on your source.
I generally crop before QTGMC and add borders after, but it is ok also as you did.

Bacause is very similar to Hauppauge USB-Live 2 I own (CX23102 video chip) and because I have seen several captures in the forums and from friends.
But this card went several hardware variants, so better to trust hodgey and experiment yourself loooking to the histograms after a capture at default procamp settings.

My understanding is that DVD video can be either 704 or 720 pixels across, and a DVD player uses a 720x576 frame to create an analog signal, adding 16 pixels on the sides for overscan if the source video is 704 pixels across. For a digital signal (HDMI), it uses a 704x576 frame and removes 16 pixels if the source video is 720 pixels across.

So whether you expand the frame to 720 pixels across depends on whether you're preparing the video for analog or digital display. For digital, just keep it at 704 pixels across.

Yes, AddBorders() should go after QTGMC or anything else that sharpens, otherwise it sharpens the border and that looks ugly. Try it and see!

Crop() of course must go somewhere before AddBorders(). I put it immediately before like you did just so it's easy to see how much border I should add.

You should be able to see in the virtualdub live histogram whether there is anything going inside the red areas. If it's clipping somewhere it won't go below/above a certain spot.

Thanks for the advice on this. As you can see there are basic fundamentals I want to get correct (before moving on to some tricky questions I have on restoration).
I would prefer to be 'adherent to specifications' especially for the frame size. So if I have understood your advice correctly can I assume however much I Crop off the side borders and bottom head switching noise, I should always AddBorders to ensure the frame size is 720x576?

Remember my source is VHS and my end delivery is H.264 to watch on TV - which I understand is YUV at capture, processing, encoding and final viewing (i.e. Lagarith, AviSynth+, H.264 and TV screen).

[QUOTE=lollo2;81496]
The "faster" preset or defaults setting in QTGMC tends to give a plastic look and oversharpen, but that really depends on your source.

I thought the "Slower" preset produces a plastic look. LordSmurf advises to use "Faster".

I tried AVISource but receive this error in AviSynth+
AVISource: couldn't locate a decompressor for fourCC LAGS

So I stayed with FFmpegSource2 (I use version 2.23.1 as I read that version 2.40 corrupts video frames).

I ConvertToYUY2 because my captured file seems to be YV16 according to AviSynth+. Maybe I have configured the Lagarith Compression settings incorrectly in VirtualDub2. Do my attached settings look correct? I think I had unticked the 'Source' box on one test capture.

I included the -aspect 4:3 in my FFmpeg script:-

Yes

https://forum.videohelp.com/threads/...l-recommend-it

Experiment yourself and compare. Fast preset is reccomended to avoid heavy, and sometime useless, extensive noise processing, which cannot be completely avoided anyhow. All given presets, including default with QTGMC(), "fast" and "slow" tends to introduce artifacts such as waterpaintings plastic look, in addition to temporal mismatch and blocks misplacement.

You should not capture with VirtualDub2 but install Lagarith or HuffYUV codec and capture with VirtualDub 1.9.11 or AmarecTV.

Your ffmpeg command is fine.

Checking in the Histogram with default levels, my VC500 seems to have a hard left border around Y=16. At the right hand end I have seen reds almost to the end of the Histogram, so I think this shows my VC500 is capable of capturing 16-254.

I have managed to get VirtualDub 1.9.11 working with my VC500 on this Windows 10 workflow, so I will use that for capture. It is very temperamental getting the preview to appear - changing the preview acceleration back and forth and turning the Histogram or Cropping on and off somehow makes the preview finally appear. I could never get it working previously so I was using VirtualDub2.

After doing some testing I also established the cause of AVISource() throwing the error 'AVISource: couldn't locate a decompressor for fourCC LAGS'. This was when processing an AVI I had trimmed in VirtualDub2 and saved using 'Direct stream copy'. But when making the clip again today using 'Fast recompress', that clip could be decompressed in AviSynth+ by AVISource().
I always have Audio on 'Direct stream copy' if I am not making any changes and leave it uncompressed. What is the correct setting under the Video menu when only carrying out simple cut/trim edits that do not require re-encoding the video?

Also, back to my original question in this thread about Levels. Knowing that my capture device can capture at 16-234 should I capture at this range by adjusting Levels whilst watching the Histogram to ensure they do not (or only very slightly) go into the red at the left (Y=16). As long as there is no vertical red line at the at the very right (Y=254,255) there should be no clipping of white?

If I understood that correctly then the capture can be 'shrunk' to TV levels (16-235) during processing in AviSynth, but the master capture will be as full range as I can obtain?

There's no need for any of that. Just add Trim() to the beginning of your script, like this:

The two numbers are the numbers of the first and last frame to keep.

Strange, in VirtualDub (not 2) when you specify "Direct stream copy" the saved file is untouched in its original codec compression.

Yes, this is what I would do.

Yes. You can use Levels(16, 1.0, 254 (*), 16, 235) or ColorYUV(cont_y=..., off_y=...) or ColorYUV(gain_y=..., off_y=...).
If you choose Levels() better use a variant non acting on croma.
If you do not see in the histograms of your capture Y > 235 do nothing (use here Histogram("levels"), or Histogram() or ColorYUV(analyze=true)).

edit: (*) or the highest value you measure

Thanks lollo2 and traal. I have been reading a good few of yours and others posts on capturing levels.

That makes sense now to capture the lossless AVI file at the full luma range available with the capture device, using the Histogram to avoid clipping against the full range. In my case avoid clipping beyond Y=16-234.

I read that colour space is YUV in Lagarith, AviSynth and 'Television'. VirtualDub and computers use RGB. I am getting confused by this. Not so much with VirtualDub because I will only use it for capture, so the lossless AVI file is YUV. But my confusion is in relation to 'Television'.....
my final delivery is MP4 (H.264) to play back using VLC on a HTPC connected to my Smart TV via HDMI. So my 'Television' is effectively a computer screen. Is my TV displaying in RGB or YUV in this scenario?

I want to ask some questions about ColourMatrix and Rec.601, but will come onto that once if you can help me understand the above correctly.

It I remember correctly, a HDMI connection can carry both RGB and YUV color space.

If you generate the final video by ffmpeg, sourced by an avs script not including any color space manipulation, your signal will then be YUV. Thus the HDMI carrying YUV should be fed with levels in the standard 16-235 range (add a last line at the end of your avs script). The TV will convert YUV levels 16-235 to RGB 0-255 and display it properly.

This is the theory. However, the best is that you experiment the different options and judge yourself if the theory is confirmed, but also what's best for your devices and to your eyes.

Just for curiosity and a bit out of contest: for some of my captures, in my avs scripts I start shrinking the 16-254 range to 16-235 (standard procedure), I end up after a full extensive filtering with 0-255 levels because filter processing (standard procedure, not depending on me), and I add at the end a level conversions to 5-255 to have a better black levels (not standard procedure, just my personal taste). I will finally check if playing directly (through a Samsung utility) the mp4 video on my TV is ok (leave as it is) or not (16-235 supplementary conversion required).

I remember reading your post about shrinking and expanding levels in stages due to some filters requiring the levels to be within 16-235 in order for them to work correctly. That was getting too advanced for me at the moment :) Maybe in more time I can get to that stage. At the moment I am still ironing out the fundamentals of my basic workflow and you have helped me rethink a few steps I thought I had already nailed.

I'm not sure if it is VLC that will decompress the mp4 file into an RGB or a YUV signal. Or if the TV (Panasonic TX-50CX680b) receives and displays the YUV video or must it convert it to RGB as it is acting as a computer screen?

IIRC you can set something about YUV/RGB in VLC, do not remember where ...

edit: beeing many elements involved in the flow from capture to display (input levels, avs levels, ffmpeg levels, pc player levels, connection (HDMI) levels, display levels) is better you carefully check each step, an unwanted color space conversion can be hidden everywhere. Not easy...

At default settings my VC500 is showing levels down to Y=0 in the Histogram (see attached screenshot). Does this confirm the device can capture from Y=0 ?

Mine has gone back to showing a hard border in the Histogram at Y=16. VirtualDub 1.9.11 keeps reverting the video standard to PAL_D (I get no picture in Preview), instead of PAL_I where I need it to stay.

I have gone into EZ Grabber and made sure the video standard is set correctly.

Any idea how to get VirtualDub to remember the correct video standard?

VC500 should be in 14-245 range http://www.digitalfaq.com/forum/vide...html#post62640

To find exact values, run ColorYUV(analyze=true) on a capture and "read" the numbers

EDIT: check about setting sharpness at 0 with procamp, same argument as per levels https://forum.videohelp.com/threads/...ure-in-procamp

if you whish to write the values to a file for further processing you can use this code:

Hey London. I just wanted to thank you for this thread. Like you, my workflow has been similar JVC SVHS -- ES15 -- VC500 -- Win10 -- VirtualDub2 with Lagarith -- AVS script with AviSynth+ and VirtualDub2. Your questions are exactly what I am struggling with, including the problems with VirtualDub1911. Just wanted to let you know I appreciate this thread. Please post your final AVS script when you finalize it.

Question for you: I feel that most of the AVS scripts I find online are for AviSynth and VirtualDub1911 (32-bit everything). The only reason I went with AviSynth+ and VirtualDub2 was this Andrew Swan video: https://www.youtube.com/watch?v=C4PyyQoz6eo. Was that why you went that route, and are you considering switching to AviSynth and VirtualDub1911 for the processing (after capture)?

Hi ThumperStrauss. Thanks for the encouragement. It is reassuring for me, being a novice, that others have very similar setups and experience the same issues as me.

I did indeed follow that tutorial video from Andrew Swan (and his earlier videos for 32Bit and 64Bit side by side installation) and together with some particular fixes (for Microsoft Visual Studio installation) mentioned on his blog page I was able to get VirtualDub, AviSynth+, AvsPMod and command line FFmpeg setup correctly. Also prior to setting-up my Win10 workflow I have been using VirtualDub 1.9.11 + Filter Pack (from this forum) installed on my Sony VAIO running XP, that computer has an AV docking station with S-Video and Composite Inputs and Outputs which I used for some test captures. Anyway that is a different workflow, my questions here are for my Win10 workflow with the VC500 USB.

I read a lot of posts in the capture forums here and could read many more. I fully appreciate that we can do better than a VC500 USB and Win10, by using an ATI Theatre 200 chip AGP card on an XP machine with all the correct drivers. Those are the best cards built for the analogue capture era. Then there are proven good VCR's such as the Panasonic NV-FS200B, some JVC's etc, DataVideo TBC..... If I was going to do it 'properly-properly' I would know what to get, but I am not there yet.

After reading a lot of posts it can be tempting to get too far ahead of yourself, getting into restoration filters such as Deshaker, spot removal, chromafix. All in time. What I have done is 'rewound' to establish a basic workflow for my Win10 setup. With the help here, particularly from lollo2 and traal, I have re-learnt some fundamentals I thought I had already moved past. For example, do not resize in Avisynth. You will see the posts above....capture at 720x576, Crop 16pixels off the width and add 16pixels to keep the frame size 720x576 but the display area is 704x576. When encoding you can set a flag for the DAR to be 4:3.

I was using VirtualDub2 because VDub 1.9.11 was not 'playing nicely' with my VC500, but now I have got VDub 1.9.11 working. If your Preview ('Overlay' never works for me) does not display anything, then sometimes switching the Video standard to MESECAM, then back again to PAL_I kicks the Preview display into action on mine. Also, before you even launch VDub, open EZ Grabber and make sure the video standard is set correctly there - that should be a one time setup, but mine had changed.

I am back at work now so have little time to post until the weekend maybe, but I do want to follow-up with some notes from my testing over the weekend. After Lollo2 suggested to use AVISource() instead of FFMpegSource2() I was trying to remember why I had moved from AVISource() as my source filter. I think it was because my MP4's encoded when the source filter was AVISource had no audio when played back using the media player in my Panasonic TV. I need to test that again. I think using FFmpegSource2() fixed that problem and maybe that is because I use command line FFmpeg to encode the file. Anyway, I will be using VLC on my HTPC connected to that TV to view my files, because the media player built into my Panasonic TV is not very user friendly when I have many, many videos and pictures in my library.

Another item I noticed whilst testing yesterday is that FFmpegSource2() was reporting frame rates at 24.907, whereas the exact same clip when changing the script to call AVISource() showed the frame rate at 25.000. Completely fathomed by that one. I thought my Timing Settings in VDub needed looking, but that does not explain the difference in frame rate for the same clip. Some have reported that FFmpegSource2() corrupts frames (see Andrew Swans blog). btw that test I did in VirtualDub 1.9.11, VirtualDub2 64 Bit Lagarith.dll and VirtualDub2 64 Bit Lagarith.vdplugin - all 3 had strange frame rates when the source filter was FFmpegSource2().

I need to check using ColorYUV(analyze=true) what range my VC500 USB can capture, based on the advice from lollo2. Once I have done that I will post a 'final script' and hope that my help others in a similar situation to me.

I

Just to be clear, do you mean make sure the Video Format is set to "NTSC_M" (if one is in North America)? Or is there another setting I need to check?

Yes make sure that Video Format is set correctly in EZ Grabber. Then restart your computer.

You shouldn't have to launch EZ Grabber again, the Video Format setting should be as you set it, but if you are randomly not getting a Preview to appear in VirtualDub it is worth checking that EZ Grabber is still set correctly.


When you launch VirtualDub 1.9.11 check the Video -> Capture Filter is also showing the correct setting ("NTSC_M" for yours).

Just to confirm that you're working with NTSC and not PAL, given by your username (I appreciate there's one in Ontario too) and you've mentioned the FS200 which is a PAL machine?

I have mine set to 'PAL_I', that is the correct setting for my region (UK).

Ah cool, there's no many of us on here, whereabouts are you? London I guess?

Just needed clarifying as some of this was getting a bit mixed up with NTSC.

I have now carried out two test captures of the same VHS clip in VDub 1.9,11 using the VC500 USB. The first one allowing the levels to spill into the red zones in the Histogram (but not slamming against 0 or 235). The second one setting the Levels to generally keep out of the red zones in the histogram, so should be within Y=16-235.

Running ColorYUV(analyze=true) in AviSynth the results of the first capture are shown in 'ColourYUV full levels capture' and the results of the second capture are shown in 'ColourYUV legal levels capture'.

What do the Luma Y results mean for each capture?

You should let the card to capture with its default setting, no procamp adjustement.
Then, you need to remove (crop) in AviSynth all black borders and the head switching noise at the bottom.
Then you run ColorYUV(analyze=true) and read in the "Luma Y" values moving through the different frames:
Minimum and Maximum are the min and max values for the luma in the current frame; moving to many frames, this will tell you what range the card can capture.
Loose Minimum and Loose Mazimum are the min and max values for the luma in the current frame ignoring the brightest and darkest 0.4%.

If you use the script I posted, playing for a little bit the video loaded in VirtualDub, it will generate a file will all this information, that you can easily open and check for hisghest and lowest Y values

Thanks for the explanation lollo2. I will do another test at default settings to be absolutely certain of the capture range capability.

Just to clarify, this was the script I used for those tests in my previous post:-

As you can see I cropped a bit extra to make sure there were no black borders or bottom head switching noise affecting the ColorYUV readings.

I think this concludes that my Diamond VC500 USB can capture luma from 1 to 254.

This brings me to an important point about capturing. There are 2 schools of thought (probably more), but basically:-
a) creating captures using the full range capability of the capture device (in my case Y=1-254); or
b) creating captures to broadcast safe/legal levels (Y=16-235).

When I captured with the full range - pushing the Levels in the VDub Histogram to just touch the 1 and 254 positions, the video appears to have too much contrast. Whereas adjusting the Levels to keep within the Histogram Y=16-235 the video appears more natural.
The video I am testing with was created by a professional videographer. My thinking is that this tape may have been mastered with luma values within 16-235. Therefore the source I am dealing with in this particular instance has a luma range of 16-235, so I should capture at that range? Does this sound correct, or should I still capture at full range?

Maybe I was not clear, sorry. You should not push anything, just capture at the default of your card. Eventually shrink (never expand) to avoid clipping and crushing.

My school of thought:

• leaving the card at its default allow you to capture what is on tape without modification (when not clipping whites or crushing blacks)
• if you need to adjust the levels later for whatever reason you can do it with AviSynth in a more effective way than with procamp
• in order to judge colors and levels you need trained eyes and calibrated monitors
• use procamp only to avoid crush of blacks and clip of whites (not always possible, https://forum.videohelp.com/threads/...ng#post2580749
• if your source is 16-235, and has been mastered as such on tape (not sure), it should be captured in that range with the default setting; if you see differently I assume on tape is not 16-235

Your, and others, mileage may vary!

Thank you for the advice lollo2, it is much appreciated and has helped me understand the principles of optimum luma settings at capture stage, as well as the capability of my capture device.

Some summary notes, since I started this thread and what I have learnt:-

(note: My source is PAL VHS
My workflow is VHS -> Composite -> Panasonic ES10 -> S-Video -> Diamond VC500 USB, Windows 10).

Use VirtualDub 1.9.11 for capture, Lagarith YUY2 compression.
Capture at 720x576 (for PAL).
use default proc amp settings - only adjust Levels to prevent crushed blacks and clipped whites.
Video menu, Capture Filter (check 'Video Standard' is set correctly), clicking OK should make the 'Preview' window appear. 'Overlay' does not display the video.

It is not necessary to resize in AviSynth.
Crop 16 pixels off the sides and add black borders to keep the frame size at 720x576 with the display area at 704x576 (this is as close to Rec.601 spec, 702x576, as possible with Mod4).
Use AviSource() as the source filter. Keeps the video in YUY2 and shows the correct frame rate.
FFmpegSource2() converts colour space to YV16 and strange frame rates (sometimes).

For those following this thread that had asked, my final basic AviSynth+ script for deinterlacing and cropping out the non-visible content of the video, is:-

and my command line FFmpeg for creating an MP4 is:-

All right except:

should be Crop 16 pixels off the sides to reduce frame size to 704x576 (this is as close to Rec.601 spec, 702x576, as possible with Mod4).

should be:
In general, in a complex AviSynth filtering you completely removes black borders and head switching noise then at the end center the active area and fill with black borders at left and right to reach 704x576:
Edit: also check QTGMC parameters to avoid artifacts according to your source

I had been following your advice from Post #5 and had also read further about ITU-R BT.601, for example here:-
https://www.afterdawn.com/glossary/t...m/itu-r_bt_601

Isn't the Frame Size 720x576 and the Active Area 702x576 ?

PAL VHS uses 702 pixels of the available frame size, DV might use all 720 pixels, but to maintain the correct 4:3 aspect ratio of the source the frame size should remain as 720x576 ?
Hence:-

would achieve the ITU spec compliant aspect ratio when encoded out ?

Looks cromulent to me with a fast burst of mental arithmatic.

If you're cropping overscan or associated junk into the mix obviously you'll need to readjust, but it sounds to me like you've got more than the gist of how this works. :congrats: