Choppy captures, VirtualDub, 720x480 output?
 

Workflow:
JVC - TBC - Pinnacle 510 - Vdub 1.9.11 - Huffyuv. Everything works great when the output is set to 352x480. Pretty smooth playback w/ good audio for VHS's from mid 90's. When I try to capture in 720x480 I run into choppy video captures. Could this be the computer itself just being slow? I have read through this forum until my eyes hurt many of nights to get to this point, I feel like I'm almost there if I can get over this hurdle. Running Windows 10 Pro if that helps. Thank you

The answer you'll probably get is that Windows XP is the "more recommended" OS for virtual dub captures. So I guess if you have the means, you might give that a try?

Don't have access to XP device, I've seen others have success here with Win10. Just not sure if it's a particular Vdub setting issue or computer issue. Have searched the forum but can't find a solution

What cpu/gpu usage does vdub report when you use the different capture resolutions?
Also try to click ctrl + shift + escape to see resource usage or use another method to see how much you have left.

Thank you for the response...
720 - will get up to 30-33% CPU usage
352 - got up to 22% but settled in around 9%

I attached pictures of both during the captures with each
Edit- not sure why pics are sideways, they aren't when I look at the files on my comp

Video / No Display (nope, you can't watch what you're capturing).
Audio / Uncheck "enable audio playback". (nope, can't listen either).
In my case both of those caused unusable captures at 720x480.

I monitor the tape with an old TV connected to the Composite (yellow) RCA of the VCR and the Black and Red Audio split with a Y cable.

Histogram off too. In fact, can you send a better screen shot? Maybe there is something else we can see that's causing problems.

Thank you. The audio playback has been unchecked on all these. I turned off the display and have no histogram, no change. I uploaded the last test run screenshot based on those changes.

30% CPU usage seems like a lot, but maybe that's just how windows 10 is. My XP machine uses like 15% CPU at most and that's just a Core2Duo.

I assume you are capturing the files to a different drive than what the operating system is running on? That's generally a must as well.

Yes I have a large external drive I'm capturing to.

Grasping at straws now...
Don't use compression (test run anyway).
Make sure an Virtualdub filters are not being used - Video/Filter Chain
Recording to a local C drive and not network or USB?

24 fps is wrong, capture at 29.97 for NTSC.

It shows 29.97 on Vdub

I was capturing to a large external drive, switched to an internal and that seems to have cleared it up! You and billct97 both mentioned that and I appreciate all the help!

You should be able to have your preview on and capture in windows 10.
Do you have your wifi disabled?
Is your firewall and antivirus scanning disabled?
Are you capturing to a separate HDD from your OS?
Are you using Huffy?

That weakens your signal. It’s really tough to get a good CRT too. It’s better to preview in Vdub.

This was in your 720x480.jpg:

Attachment 18963

So it appears to be doing an inverse telecine during capture, and you don't want that.

LOL, I'm using XP for my capture machine which is only rock solid with Video and Audio Preview turned off while recording in VirtualDub. I've tried a W10 and W11 machine (and a 2250 Hauppauge card) all with completely different results. I feel that the old Sony 4:3 TV is the best way to monitor while recording blind.

You do have an interesting point that using both S-Video for the capture and the yellow composite RCA for the monitor might affect the S-Video signal. I suppose I could instead use the CH3/4 RF modulated output instead? Which brings up another thought... is the RF modulator also reducing the available video signal? In which case maybe I should unplug the modulator input as well so that 100% of the video signal is present on the S-Video output. Seems like overkill but is it?

How many GHZ does your CPU have?

It has 3.20 Ghz

Not sure what the means, can you elaborate? settings were set to the 29.97

I'm not sure if that was to me or Scottymac22 but it's worth noting that if I enable Video (Video / Preview / Preview Acceleration - Interlaced Frames) while capturing I was surprised to see just a few Dropped and Inserted Frames right at the start of capture. Overlay doesn't work at all on this machine. It looks like a good capture with Video enabled but I notice that the Video Average Rate goes up from 29.9700 (or close to it) to around 30.4300. I also tried with Compression Off (I use Lagarith) and just for fun with the Histogram on and off (it actually worked while in Capture). But in all cases the only way to get a constant 29.97 is with Video Off. CPU is an Intel Core 2 Duo T9400 @2.53GHz (Lenovo T500 laptop running XP). With Video On CPU would bounce around 5-35% with occasional spikes to 65%. Also, I don't see any effect removing the Composite Video while Capturing. Unless others insist that is a bad idea I think I'm going to stick with my original setup but do appreciate the advice.

I take this earlier reply to mean that your original problem (reason for this thread) has been solved by switching from the external (USB I assume ???) drive to an internal drive.

That makes sense as capturing to a USB drive is often sketchy at best. Some people have success, most don’t. It probably depends on the exact hardware and how everything is connected. I suspect it’s even less likely to work if the capture device is also a USB device.

As an aside, even on the latest, quite powerful hardware, just moving a USB mouse spikes CPU activity. “Buildzoid” (Actually Hardware Overclocking) has some very interesting, but sadly very long, videos on YouTube discussing Intel 14900 degradation issues and ways to control things to avoid it. One of the curious things he demonstrates it that when things are on edge, moving the mouse around will push them over the edge and crash things like Cinebench R23 while/by spiking the CPU voltage requests. My take away from this is to avoid as much USB, esp. mouse activity to as possible when capturing.

BW