digitalFAQ.com Forum

digitalFAQ.com Forum (http://www.digitalfaq.com/forum/)
-   Capture, Record, Transfer (http://www.digitalfaq.com/forum/video-capture/)
-   -   First VHS capture, advice on levels? (http://www.digitalfaq.com/forum/video-capture/12375-first-vhs-capture.html)

London 12-31-2021 10:34 AM

First VHS capture, advice on levels?
 
2 Attachment(s)
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?

traal 12-31-2021 11:34 AM

Quote:

Originally Posted by London (Post 81482)
I capture as lossless AVI using Lagarith, YUY2, PAL_I, 768x576... 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.

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.

London 12-31-2021 12:43 PM

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)

traal 12-31-2021 06:34 PM

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
Code:

-aspect 4:3
to the command line and players will understand it if your container is MP4 or MKV.

lollo2 01-01-2022 04:46 AM

Quote:

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)
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.

Quote:

Have I correctly set Levels for this clip?
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.

London 01-01-2022 08:46 AM

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 ?

hodgey 01-01-2022 09:23 AM

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.)

London 01-01-2022 10:09 AM

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?

lollo2 01-01-2022 10:21 AM

Quote:

Essentially it is better to correct the aspect ratio when encoding then, rather than resizing in AviSynth
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:
Code:

ffmpeg -i <input_file.avi> -aspect 4:3 -c copy <output_file_dar.avi>
This last is more a theory than a good practice, because you will end up with a new additional very large file!

Quote:

I will crop 16 pixels total off the left/right. Should I then add black borders to maintain the frame size at 720x576?
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.

Quote:

Did I call Crop and AddBorders at the correct place in the script?
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.

Quote:

Also, out of interest, how can you establish that the Diamond VC500 USB can capture Y=16-254 ?
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.

traal 01-01-2022 11:27 AM

Quote:

Originally Posted by London (Post 81492)
I will crop 16 pixels total off the left/right. Should I then add black borders to maintain the frame size at 720x576?

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.

Quote:

Originally Posted by London (Post 81492)
Did I call Crop and AddBorders at the correct place in the script?

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.

hodgey 01-01-2022 12:05 PM

Quote:

Originally Posted by London (Post 81495)
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?

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.

London 01-01-2022 12:53 PM

1 Attachment(s)
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:-

Code:

ffmpeg64 -i "VHSclip.avs" -c:v libx264 -preset slower -crf 18 -aspect 4:3 -c:a aac -b:a 128k "VHSclip.mp4"

lollo2 01-01-2022 02:45 PM

Quote:

can I assume however much I Crop off the side borders and bottom head switching noise, I should always AddBorders...
Yes

Quote:

I thought the "Slower" preset produces a plastic look. LordSmurf advises to use "Faster"
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.

Quote:

I ConvertToYUY2 because my captured file seems to be YV16
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.

London 01-02-2022 12:22 PM

Quote:

Originally Posted by hodgey (Post 81501)
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.

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.

London 01-02-2022 12:47 PM

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?

traal 01-02-2022 12:54 PM

Quote:

Originally Posted by London (Post 81538)
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().

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

Code:

Trim(247,181663)
The two numbers are the numbers of the first and last frame to keep.

lollo2 01-02-2022 01:30 PM

Quote:

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'
Strange, in VirtualDub (not 2) when you specify "Direct stream copy" the saved file is untouched in its original codec compression.

Quote:

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?
Yes, this is what I would do.

Quote:

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?
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

London 01-03-2022 07:01 AM

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.

lollo2 01-03-2022 08:04 AM

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).

London 01-03-2022 08:32 AM

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?


All times are GMT -5. The time now is 07:06 AM

Site design, images and content © 2002-2022 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2022 Jelsoft Enterprises Ltd.