capture of VHS using VirtualDub - output size

[sandpipers01]

Hi. It is my understanding that camcorders from the 1990s recorded at 720 x 480, and that would be remain the same when copied onto a VHS tape. In my setup in VirtualDub, for the video capture pin, the largest output size available is 640 x 480. Am I missing a driver or other software to remedy this? Thanks.

Alison

[dellsam34]

Unless you are on a Mac, Vdub should capture at 720x480.

[sandpipers01]

Windows 10. And the test capture I did came out at 640 x 480. I was googling this and read that someone's choices changed with a windows update. I'm at a loss of how to increase my output.

[sandpipers01]

Update! I solved the issue by finding updated drivers for my VIDBOX device connecting my VCR and PC!

[ConsumerDV]

640x480 is fine unless you plan to author a DVD-Video, in which case you would need to re-sample to 720x480. With 640x480 you get a frame with correct aspect ratio, with automatically cropped overscan and with nice 1:1 PAR - easy to work with. VHS has only ~240 LW/PH anyway, or about 320 samples per line in total.

[manono]

It should be 720x480. If going directly to square pixels it would be 656x480. At 720x480 you can then crop away the black bars to 704x480 before resizing to 640x480.

[ConsumerDV]

It should be 720x480. If going directly to square pixels it would be 656x480. At 720x480 you can then crop away the black bars to 704x480 before resizing to 640x480.

I suppose, the implementation depends on a particular device, but when capturing with DVC 100 into VirtualDub2 as 640x480, it crops overscan automatically and preserves correct AR, so I don't need to do anything. This works great if overscan is equal on the left and on the right. Sure, if the frame is sort of shifted in relation to overscan so that you need to crop more from one side than from another, it is better to capture into 720x480 and then crop to one's liking.

[dellsam34]

Most tapes don't have the same black bars on the left and right especially the 8mm formats, It is always better to capture at the native sampling rate of the ADC chip which is 720 samples and crop or mask later if needed taking into consideration the AR is 704:480 not 720:480.

[ConsumerDV]

I agree, capturing full frame with overscan is more flexible.

But how do you know that the native sampling rate of ADC chip is 720 samples? VirtualDub simply presents all available modes that a particular ADC is capable of, depending on ADC I see different values. So if I select 640x480 from the dropdown I assume that the ADC captures at 640 pixels, not VirtualDub re-samples 720 into 640.

[dellsam34]

It's by design, Never heard of Rec.601 standard? All capture cards are designed on that same standard except some few modern chinese knockoff's that use PC resolutions.

[ConsumerDV]

Rec 601 defines the format of component digital video and the way analog-digital as well as 525/60 and 625/50 interoperate. I don't see the direct relation to how a particular ADC samples video. My point is that properties like frame rate, frame size, color subsampling, etc that a capturing program displays come from a predefined list that is provided by the ADC. For example, when you switch from 29.97 to 25, the ADC samples video at 25fps. I presume that similarly, when you switch from 720x480 to 640x480, the ADC samples at 640x480 - in hardware. I may be wrong, of course.

[dellsam34]

That's what rec.601 was created for, to standardize analog to digital video conversion not to pasteurize milk. Just lookup capture cards specification, When you see rec.601 that's what it means, Resolution is just part of the standard and no the ADC never samples at 640, 640 is a computer resolution, it didn't exist when the standard was laid out, It is a computer resolution, Apple started it I believe.

[ConsumerDV]

That's what rec.601 was created for, to standardize analog to digital video conversion not to pasteurize milk. Just lookup capture cards specification, When you see rec.601 that's what it means, Resolution is just part of the standard and no the ADC never samples at 640, 640 is a computer resolution, it didn't exist when the standard was laid out, It is a computer resolution, Apple started it I believe.

Thank you for taking time for providing this invaluable information. Do you know for sure that "the ADC never samples at 640"? Do you know what exactly happens when I select "640x480" frame size - does the ADC sample at 720x480 then re-samples to 640x480, or does the software strip overscan then re-samples to 640x480?

Regarding your fixation on 720x480 frame size, I can quote the following gentlemen:

Prof. Lenny Rudin (1, 2, 3)
Ping Yu (1)
Prof. Jean-Michel Morel (2)

Cognitech, Inc, Pasadena, California (1)
Ecole Normale Superieure de Cachan, France(2)
SMPTE Member (Hollywood Technical Section) (3)


Sampling Theory for Digital Video Acquisition: The Guide for the Perplexed User

There has been confusion recently, regarding the sampling rate of video images. Some systems sample a frame with 720x486, which is originally known as CCIR-601 Component Digital Standard, and other systems use a 640x480 rate, square pixel standard. It has been wrongly claimed that the CCIR-601 standard is the only right standard to use when digitizing images from composite video sources such as NTSC, PAL, and SECAM. The origins of the CCIR-601 standard have no relation to improving digitizing composite video from e.g. (S) VHS videotapes.

The CCIR-601 format is a choice preferred over 640*480 only from the point of ease of conversion between various composite and component video formats that include high end component technology recorders (used by news channels, and not by CCTV systems), and not because there is any loss of information when sampled at lower rates.

The choice of either of the two sampling rate formats has no relevance to the claims of better image quality when, for example, images are collected and recorded on VHS or SVHS video. 640*480 sampling rate represents approximately 20% - 30% over-sampling (depending if we count the non-image part of the frame that is approximately 15%). Therefore, any further over sampling is simply redundant.

The SVHS video cameras generate luminance signal with maximum frequency of 5MHz, which then gets recorded on the SVHS video tape. The corresponding Nyquist Rate is 635 samples per horizontal line, and if adjusted for the percentage of active image information, the minimum number of pixels needed per scan line is 540. Thus sampling at 640 pixels per scan line represent about 16% over-sampling over Nyquist Rate, which is more than sufficient to avoid any information loss.

Video can still be sampled at horizontal length of 720 pixels and vertical rate 486. However, no new information is gained by over sampling at this higher horizontal rate.

And further:

The cards that the authors used in this paper both have under scan capability. Even more so, some of the 640*480 cards originally sample at 720*486 rate, then rescale it back to 640*480 to preserve the original geometry ratios. This is simply down sampling of the over sampled image, done in a careful way.

Therefore, if one wants to work with 4:3 frame with nice square pixels, I don't see why such rescaling - or sampling directly at 640x480 - cannot be done by ADC "in a careful way".

[DB83]

I know I should not involved in these discussions. But....

That article you quote from is almost 20 years old. The authors admit that they used capture cards that rescaled. Yet did not quote any detail. Even so the premise of the article concerned CCTV and not home video. But back in the day I also owned a capture card ATI AIW that preported to 'capture' @ 640*480. Yet it troubled me in PAL Land how one could 'carefully' resample what should be received by the device at 720*576 to 640*480 in real time and not have interlacing issues. So I changed the card (PCI-based) to one that stuck to the SMPTE/ rec 601 standard.


Even my current device (usb) only has capture pin options of 352*288 (default) and 720*576 in vdub


And if 640*480 is so fine then do explain, since you appear to have the knowledge about DV, why that was not set at 640(656) * 480 PAR 1:1

[dellsam34]

.

I don't think you understand all what you have posted above.
- It says Rec.601 preferred 720 over 640, Not true, You know why? 640x480 video hasn't existed yet, IBM standardized VGA 640x480 in 1987, 5 years after rec.601.
- No one claimed one resolution is better than the other, I don't know why you are making up these arguments, I just stated to capture native 720 and crop later so you control the frame vs cropping on the fly and hope for the best.
- It clearly states that the authors cards have under scan capability, meaning it samples at 720 and downscale to say 1/2 D1 on the fly, Also it stated it can rescale to 640 from 720 on the fly, PAL cards can resize on the fly to 768 from 720 for square pixel.

Think of 720x480 (486 only pro capture devices) or 720x576 as an imaging sensor, it is locked by standard to that resolution and the capture software can resize to any resolution, except as you stated there is no quality benefit other than having square pixels which is no longer a problem from a decade or so ago, Plus the age of 640x480 monitors has looooong gone.

[ConsumerDV]

Yet it troubled me in PAL Land how one could 'carefully' resample what should be received by the device at 720*576 to 640*480 in real time and not have interlacing issues.

Nowhere have I mentioned changing the number of scanlines. For PAL, PAR 1:1 would be 768x576, but I was talking primarily about NTSC.

And if 640*480 is so fine then do explain, since you appear to have the knowledge about DV, why that was not set at 640(656) * 480 PAR 1:1

I suppose, they took Rec 601 for the ease of standards interoperation. I am not sure how DV is relevant in the thread about digitizing VHS, which has much lower effective resolution. As I noted above, if the goal is authoring a DVD, then carrying D1 resolution all the way through is preferable. If not, then 640x480 is easy to work with and does not lose any detail compared to 720x480. But since most people upscale to 1440x1080 for YouTube, the argument is moot

[dellsam34]

Who took rec.601 for the ease of standards? When the ITU finalized the rec.601 standard in 1982, VGA (640x480) hasn't existed yet, it would take another 5 years for IBM to standardize it in 1987. By that time converting analog video to digital standard has been established and capture card manufacturers had to follow the official video standard not IBM display monitor standard.

[Sharc]

As I understand it, the luma sampling rate for producing square pixels has been defined as
12 3/11 MHz for NTSC
14.75 MHz for PAL

The luma sampling rate for digital video has then been standardized to 13.5 MHz, same for NTSC and PAL, leading to non-square PixelAspectRatios like
12 3/11 : 13.5 = 12:11 for NTSC
14.75 : 13.5 = 59:54 for PAL

This sampling rate with the scanline duration determines the number of horizontal pixels

See also the discussion here for more details, especially post #13 onward:
https://forum.videohelp.com/threads/404626-How-do-i-upscale-PAL

[DB83]

But who says that 720*480 loses detail ? You and that guy who 'invented' his own sampling as mentioned in that paper.

You are happy to accept that DV follows the standard even if it then displays as 640*480. Any detail lost now ?


That AIW wanted to 'capture' PAL sources @ 640*480. I have never been aware of a card, certainly not a consumer one, that captures at 768*576 , and I agree, that is pure 4:3 which is how PAL 4:3 mpeg2/DVD/DV is displayed as. Mind you my original Matrox card captured as 704*576.


And trying to shift the discussion to upscaling is certainly moot.

[Sharc]

... And trying to shift the discussion to upscaling is certainly moot.

I am not trying to shift the discussion to upscaling. Just making a reference to the number of horizontal pixels and the non-square (anamorph) origin of sampled video.

[DB83]

I was not refering to you, my friend. See the last comment from our new 'expert'

[lollo]

our new 'expert'

The luma sampling rate for digital video has then been standardized to 13.5 MHz, same for NTSC and PAL, leading to non-square PixelAspectRatios like
12 3/11 : 13.5 = 12:11 for NTSC
14.75 : 13.5 = 59:54 for PAL

This sampling rate with the scanline duration determines the number of horizontal pixels

This says it all

[ConsumerDV]

This has been a lively discussion, but I am not sure what the argument is about. It is like twenty people shouting in a bar. Your bourbon is as good as my scotch Two of my points are:

• I posited that using 640x480 instead of 720x480 for capturing NTSC VHS is quick and easy and does not lose information (except of overscan). I still stand by this assertion. I did not mention PAL.

• I also posed a question: what happens when I select "640x480" frame size in VirtualDub capture dialog:
  • does the ADC strip the overscan then samples at 640x480?
  • does the ADC sample at 720x480 then strips the overscan then re-samples to 640x480 internally?
  • does the ADC sample at 720x480 then the software strips the overscan and re-samples to 640x480?

I guess I can ask VirtualDub devs about the #3, but ultimately it seems any of these options is possible and satisfactory.

Rec 601 is a standard for digital component representation and interoperation, it has no direct relation to VHS. Anyone who wants to learn about the development of Rec 601 can navigate to EBU.ch, there are a couple of interesting articles there. I don't know where the topic of VGA came from.

Just because ADC uses 720 samples per line does not mean that 720 samples are somehow "native" to VHS. But I understand that it is easier to have everything using the same standard, namely Rec 601 for, well, interoperation. Outside of professional realm there is no need to stick to this standard, and if one wants a file to play on a computer or to upload to YouTube, then 640x480 with square pixels is as good as 704x480 with rectangular pixels. Considering that some old containers are flaky regarding metadata, square pixels is the safe common denominator that always works. By capturing into 640x480 one skips a couple of steps, namely removing overscan and re-sampling. This is the format that is easy for newbies.

Never have I said that 640x480 is better than 720x480, I simply said that it is as good as 720x480 and is simpler to work with. I personally capture into 720x480 and work from there.

[dellsam34]

Again, you are making false claims, No one said VHS is 720 or any analog tape format for that matters, Your capture card samples at 720 by standard, not because 720 is better, they just have to come up with a number based on some mathematical calculations and voila 720 it is, just allow it to sink in and move on.

[Sharc]

• I posited that using 640x480 instead of 720x480 for capturing NTSC VHS is quick and easy and does not lose information (except of overscan). I still stand by this assertion. I did not mention PAL.

• I also posed a question: what happens when I select "640x480" frame size in VirtualDub capture dialog:
  • does the ADC strip the overscan then samples at 640x480?
  • does the ADC sample at 720x480 then strips the overscan then re-samples to 640x480 internally?
  • does the ADC sample at 720x480 then the software strips the overscan and re-samples to 640x480?

AFAIK it simply crops the frame from the top left corner as a reference, hence the captured picture will be reduced (cropped) from the right and bottom. Means it doesn't strip the overscan on the left but leaves you with an 'asymmetric cropped' picture.
The particulars depend on the capture app and the device driver though. Some may even rescale, I don't know. Some will not even react on that resolution setting but just capture at 720x480 (NTSC) or 720x576 (PAL) respectively, including the left and right black padding bars.

[Skiller]

Do you know for sure that "the ADC never samples at 640"? Do you know what exactly happens when I select "640x480" frame size - does the ADC sample at 720x480 then re-samples to 640x480, or does the software strip overscan then re-samples to 640x480?

First reason, it is much simpler to have the driver scale in software to the resolution requested by the user rather than alter the base sampling rate of the ADC which is widely standardized to be 13.5 MHz (or any multiple of it).

Second reason, 13.5 MHz was chosen for good reason: it works well across the board for both 50 and 60 Hz TV systems and is high enough to capture all the information SD video signals may carry. If you sample at any less than 13.5 MHz during ADC you risk violating Nyquist theorem.

[DB83]

If someone claims that they can capture @640*480 via the Capture Pin (and this is the crucial bit) then they can do a test and compare the result with the same device at the standard 720*480 for NTSC. I would do it but it is not an option for me. But I would still like to see such a comparison.

On the other hand, vdub does have another dialog of 'Output Format' where there is a plethoria of dimensions one of which is 640*480 (another is 768*576). It adds a rider that selections are subject to the device. Theoretically, I can do that and maybe I will (if the device allows) just to see what happens.

[ConsumerDV]

AFAIK it simply crops the frame from the top left corner as a reference, hence the captured picture will be reduced (cropped) from the right and bottom. Hence it doesn't strip the overscan on the left but leaves you with an 'asymmetric cropped' picture.

Hmm, this is not what I see if I select "640x480" in VirtualDub2 when capturing with Dazzle DVC 100 - the frame is centered, and the black sides are cropped evenly.

The particulars depend on the capture app and the device driver though. Some may even rescale, I don't know. Some may not even react on that setting but just capture at 720x480 (NTSC) or 720x576 (PAL) respectively.

I agree, it depends on hardware and app. I just thought that since VirtualDub as well as other tools display a list of supported values that change from one ADC to another, then this is what the ADC is capable to send. But maybe these values are a combination of device capabilities aided with software processing. Thanks!

[DB83]

Ok. Can we see before (720) and 'after' (640) samples ?

But it sure looks as if vdub is rescaling on the fly and not capturing natively - the wording 'output format' as with the alternative option dialog kinda gives the game away.


Mind you, I would be worried if I saw a '(default)' of 352*288 having selected NTSC-M as the source.

[ConsumerDV]

Ok. Can we see before (720) and 'after' (640) samples ?

I shall add this test to my TODO list, which is already quite long. With my snail pace I cannot give any promises

But it sure looks as if vdub is rescaling on the fly and not capturing natively - the wording 'output format' as with the alternative option dialog kinda gives the game away.

This would be, basically, a re-scaling filter, applied during capture. Maybe. On the other hand maybe an ADC can switch from 13.5 MHz to 12.27 MHz and capture natively, I guess it depends on how it is clocked.