Quote:
Originally Posted by kooz
The following VHS clip takes place 38 minutes into a compilation of scenes which originated from Video 8 sources. It is a worst-case example for disrupting TBC and capture sync.
|
vhs test 01 - v10u tbc.avi has vertical frame jitter (look at the top border) that doesn't appear in
vhs test 01 - e65 tbc.avi.
vhs test 01 - no tbc.avi has bright flashing that appears to be frame timing sync errors interpreted as Macrovision effects by your capture device.
vhs test 01 - no tbc.avi and
vhs test 01 - v10u tbc.avi have unsafe brights.
If the frame hopping isn't actually on the tape, you should start your capture earlier in the tape. If the tape itself really does have these disturbed frames at the start, there's not much you can do about it. You shouldn't try frame-perfect "editing" during capture. It won't happen.
Quote:
Originally Posted by kooz
This is from an original, direct from camera to VHS EP recording
|
All of the captures made with this method are blurred and low-acutance, with discoloring and chroma density degradation that can't be corrected easily later. I see no sense in pursuing this method, if that's what you're doing. All of the "vhs tst 02" videos are low quality caps. You would get cleaner results recording directly from the original to lossy MPEG2 with a DVD recorder.
If the tape dubs are all you have available, that's what you'll have to work with.
Quote:
Originally Posted by kooz
Is there any way to log the histogram in VDub? Or is there a way to enable that same histogram view on already captured footage?
|
I'm not sure what you mean. If you are asking whether or not you can recover crushed darks and clipped brights that were already crushed and clipped during capture, the answer in most cases is no. Any correction would have to to be done in the original YUV colospace with Avisynth. Levels in captured material can be analyzed in histograms and vectorscopes with Avisynth and VirualDub but correction requires filters.
Histograms don't "fix" problems. They just show graphically what's happening.
Quote:
Originally Posted by kooz
Basically, my idea is to set the levels very low at a known fixed value and log histogram data with timecode as a "1st pass" through the tape, akin to indexing a DV tape. This would reveal the maximum values for the entirety of the tape, which could then be used to scale the levels in preparation for a 2nd (video capture) pass.
What do you guys think? Is this feasible?
|
No.
One can set levels for worst-case scenarios and tweak the results later. Most users do this. For my sister's insane home videos I have to make two captures, one with relatively normal levels, another with compressed levels for offending scenes, then tweak and assemble them later. Now you know why Hollywood spends exorbitant amounts of time setting up scenes before exposing a single frame. Home camera users don't do that. They just aim, pull the trigger and expect miracles, usually in available light (also often known as "available darkness"). That's why home video transfers are a nightmare.
6 hours of capture in one stretch is too much for most people to manage. If you expect to make a single capture that is perfect in most respects for all levels, color, and whatnot, you'll never finish capturing those tapes.
You have to post-process VHS anyway, whether it's level-safe or not.
Quote:
Originally Posted by kooz
if the editing, filtering, and final encoded product are all planned to be done in the YUY2 colorspace, is there still any reason to confine the capture to the "safe" (16-235) range?
|
YUY2 for capture is used because it most closely resembles and records the original 4:2:2 YPbPr colorspace used in NTSC VHS, and because 4:2:2 is better for clean interlacing than YV12 and better for levels control than RGB. Filtering in Avisynth's most popular filters is usually YV12, in
Virtualdub and most NLE's it's RGB. Encoding to the most popular standard codecs (MPEG2 and h.264) is 4:2:0 YV12. Avisynth is usually used for colorspace conversions where required because its conversion methods and algorithms are precise and debugged according to high quality engineering standards, which is not true for many editors.
There are reasons why y=16-235 is known as "video safe" because of the difference in the way video is stored (YUV) and the way it's displayed (RGB). During display, y=16-235 is expanded to RGB 0-255. If your YUV video is already 0-255 or broader, the extremes at both ends are clipped (i.e., destroyed). If you want 0-235 RGB for computer display only, there are methods in Avisynth for going with that using the "PC609" matrix. On encoding to YUV, most out of spec values are ignored or clipped. Websites like YouTube will clamp YUV at 16-235 for 0-255 RGB display on the 'net. If you submit RGB 0-255 to a TV station or closed circuit entity for telecast, it would be rejected. Out-of-spec luma and chroma values seen on TV will be clipped and can cause visual disturbances that your TV can't handle -- or If not "disturbed" it will otherwise look like crap.