Minimum CPU to capture full motion NTSC video with HuffYUV?

[NJRoadfan]

I'm currently planning to building an additional capture machine using a AGP ATI All-in-wonder card, and I'm just wondering what the minimum CPU requirements are for HuffYUV to capture 720x480@29.97fps without dropping frames? Recordings will be directed to a modern SATA drive attached to a PCI controller card (or onboard if I find a newer motherboard) so disk I/O will not be an issue. I have access to a Dell Dimension 8100 with a P4 1.3Ghz (1st gen Socket 423) with 384MB of RAMBus (!) RAM and a clone tower with an Asus P4B533 motherboard, 1.7Ghz P4 and 1GB RAM. Both work, although the clone tower's motherboard will need to be recapped as some are bulging. Did I mention that I really don't like P4 era hardware? FWIW I also got a Sony Vaio PCV-RX540 tower in mint condition with this batch of machines, but its doubtful that a Socket 370 Celeron 1.2Ghz/256MB RAM with Intel 815e chipset will be up to the task.

My last option if these aren't fast enough will be to seek out a late Athlon 64 x2 Socket 939 AGP board, or a late AGP LGA 775 board that can support Conroe Core2Duo series CPUs (ASRock made a funky board that has the 865PE chipset, Socket 775, and C2D support). These have the advantage of onboard SATA ports and better reliability due to lower heat and less chance of bad caps.

[jagabo]

I'm pretty sure all of those will work with Windows XP. As long as you aren't trying to filter while capturing and aren't running other applications. I was capturing with huffyuv and <1 GHz P3 CPUs back in those days.

[NJRoadfan]

Sounds good. I can honestly say my Pentium III 550Mhz machine combined with my 28GB 7200rpm Seagate Barracuda HD likely wasn't up to the task of capturing full 720x480i/29.97fps video. I don't plan on filtering real time, although I have been spoiled by my modern Core2Duo machine for capture as I can actually use the machine for other things without fear of dropped frames. I'm likely going to stick with the clone machine as its the fastest of the bunch.

My next issue will likely be fighting with early PCI-based SATA controllers, I hear they can be a pain with modern HDs. I'm going to stick with 512 byte sector drives that can be forced to SATA-1 speeds for the time being. Seems that backward compatibility isn't so great in SATA land.

[Mini-Me]

Just to give you an idea, I have an AMD Athlon 64 3000+ (Newcastle Socket 939 version) and 1GB DDR backing up my ATI AIW 9600 (XT I think?), along with a Soundblaster Audigy 2 for audio capture. I capture in the same format as you plan to: 720x480 @ 29.97FPS, HuffYUV YUY2 using driver version 6.14.10.6246 dated 8/3/2004.*

I generally get about 45-55% CPU usage while capturing. The good news is that my rig is easily fast enough to never, ever, ever drop or duplicate any frames (given the right settings), unless I were foolish enough to use it for something else at the same time. The bad news is that my CPU usage indicates that your P4 1.3 GHz is likely to struggle. I imagine it would have worked back in the day, but years of service packs and updates may have made the landscape a bit more inhospitable. It's probably worth trying before buying more hardware, but I wouldn't get my hopes up too much...

It's wise to leave some leeway in terms of CPU usage, too. I probably wouldn't feel comfortable if my CPU usage was routinely popping up over around 80%, but I might be overly conservative. Basically, I would suggest something more comparable to my own setup: A P4 in the 2.4 GHz range should do, as well as the Athlon XP series in the mid-high 2000's. An Athlon 64 like my own will have a comfortable amount of processing power to spare. I should mention that my motherboard (MSI K8N Neo-2 Platinum) does have onboard SATA ports, btw. You may want to look into Socket 754 boards too, because those were much more common than the 939 boards back in the day.


* Beware driver issues with All in Wonder cards: It can be hard to get various drivers to work, and there are three major evolutions of the driver with different characteristics and features. For instance, I'll go off on a tangent about differing capture windows: The newer drivers have capture windows of 53.333 microseconds IIRC, corresponding to the full 720 "DVD pixels." That would seem perfect, except the active window of real NTSC video is 52.655 microseconds, corresponding to 710.85 pixels...and 486 lines rather than 480 (http://lipas.uwasa.fi/~f76998/video/conversion/). Many capture cards have a "capture window" of the full 720 pixels, just to be sure to capture the entire visible signal horizontally (it may not always be timed/aligned perfectly). However, this means they're capturing a slightly wider area than necessary: If an active window of 710.85 x 486 stores a 4:3 aspect ratio signal, then to maintain perfect aspect ratio at 480 lines, the card should ideally capture a window of 702.074 pixels (52.005 microseconds). The oldest driver versions come very close to this, and I think their capture window is 52.15 microseconds, or 704 "DVD pixels." The AIW cards still capture at a sample resolution of 720x480 of course, but the older drivers take those 720 samples over a 52.15 microsecond window instead of 53.333 microseconds. The upside is that the aspect ratio is nearly perfect when you play back 720x480 as 4:3, and the downside is that you're cutting a bit off the sides (~6-7 columns), and you may still need a full-frame TBC to center the active window. If you use the newest drivers (or a capture device like the TV Wonder 650), you're likely to see a combined total of 9 or so black columns on either side of the image (assuming the original camera used the appropriate active window), and you would technically need to crop 16 pixels from the sides before displaying in 4:3 to ensure the correct aspect ratio, or the image will be a bit too narrow. The upside is greater control over whether to crop and where if you want to recover the correct aspect ratio...but the slightly wider capture window leads to slightly lower sampling density (admittedly irrelevant for VHS), and it generally means producing 704x480 DVD's. Since some players reportedly add 8 columns of black bars before scaling to your display resolution (or a 4:3 window), that may be undesirable. You could always use the newer drivers, crop 720x480 to 704x480, and upscale again to 720x480, but purists may wish to avoid that. Still, the more I think about this, the more the larger capture window seems worth it, and I might be tempted to use a newer driver in my future captures...

[NJRoadfan]

Well its a moot point now, just won a motherboard on ebay with a P4 2.8Ghz CPU for $15. Regarding the capture width, I noticed the older capture cards were limited to 704x480 (my Matrox Marvel G400 is one), but they seemed to crop a bit off of the sides. Newer cards are almost always 720x480 now.

[themaster1]

Pentium 4 HT (hyper threading, pre dual core) 3Ghz since 2006 for me, no pb for sd huffyuv

[Mini-Me]

Maybe I'm just out of touch with how much prices have fallen, but that seems like a GREAT deal for just $15. That's definitely powerful enough to give some peace of mind.

As far as the capture width, I'm not sure if you were talking about the capture resolution or the analog capture window when you referred to the Matrox card. Just in case, I should clarify that the width of the analog capture window is separate from the resolution the card captures at. For instance, I always capture 720x480 with my AIW, but those 720 horizontal samples are either spread over a 53.333 microsecond window (equivalent to 720 "DVD pixels") or 52.15 microsecond window (equivalent to about 704 "DVD pixels"), depending on the driver.

The active window of the actual NTSC signal is equivalent to 710.85x486:

• Capturing 704 pixels (52.15 microseconds) of that into a 704x480 pixel format means the capture card is cropping off the sides of the signal...but viewing the result in 4:3 will have the right aspect ratio.
• Capturing 704 pixels (52.15 microseconds) of that into a 720x480 pixel format means the capture card is cropping off the sides of the signal, then squeezing the larger sampling grid to fit the remainder...but viewing the result in 4:3 will have the right aspect ratio.
• Capturing 720 pixels (53.333 microseconds) of that into a 720x480 pixel format means the capture card is introducing extra black bars on the sides...and squeezing the actual signal to fit them in. Viewing in 4:3 will result in a slightly narrow aspect ratio. To fix it, you'd have to crop 16 off the sides and resize back to 720x480. About 7 or so of those pixels will be part of the actual image though.
• Capturing 720 pixels (53.333 microseconds) of that into a 704x480 pixel format means the capture card is introducing extra black bars on the sides...and squeezing the actual signal to fit them in...then squeezing the whole thing again to fit the capture format. Viewing in 4:3 will result in a slightly narrow aspect ratio (to the same degree as above). To fix it, you'd have to resize to 720x480 and crop 16 off the sides to get 704x480 again. Around 7 or so of those pixels will be part of the actual image though.

In other words, the capture resolution doesn't actually affect the aspect ratio. You can capture in 720x480, 704x480, 352x480, or 640x480, or whatever, and it won't affect the final aspect ratio as long as the framebuffer is directly scaled to 4:3. (All it affects is the sample resolution.) However, the analog capture window DOES affect the aspect ratio. If the capture window is too narrow, you could say that the capture card crops and upscales horizontally (in analog) to fit the capture format, and if the capture window is too wide, you could say the capture card downscales horizontally and adds borders to fit the capture format.

As it so happens, the AIW cards have a different capture window with different drivers, and you'd never know it unless you ran tests, noticed cropping with the old drivers, or noticed a narrow aspect ratio with the newer drivers. There's always a tradeoff between cropping part of the active window and having an aspect ratio that's too narrow, and you can't avoid both unless your source material didn't use the whole active window. It's not a huge deal, but it's one of those things I wish someone told me about up front when I got the card.

[edDV]

Huffyuv capture is mostly about the disk system. The CPU requirements go back to the Pentium III.

Best advice is cap to a second SATA or ATA drive. Laptops are a special case.

[NJRoadfan]

System is together, turns out it came with a Northwood P4 2.8Ghz HT, good enough for HuffYUV. Went onto YouTube for kicks, its amazing how Flash Player brings these old P4s to their knees nowadays.

[Mini-Me]

System is together, turns out it came with a Northwood P4 2.8Ghz HT, good enough for HuffYUV. Went onto YouTube for kicks, its amazing how Flash Player brings these old P4s to their knees nowadays.

They used to seem SO fast, too. Flash and Javascript seem to be picking up where Windows left off in the area of forcing CPU upgrades.

[edDV]

Flash is CPU intensive. Huffyuv is not.

[Mini-Me]

Flash is CPU intensive. Huffyuv is not.

In principle, I agree...but I should note that something is definitely eating up some serious cycles when I capture Huffyuv with an Athlon 64 3000+. My CPU usage fluctuates between 45% and 55%, and while that's not bad, you'd expect it would be much lower for a codec that used to work just fine on PIII's. I'm using an Audigy 2 as well, so the cycles aren't going toward audio capture with an integrated chipset or anything either. Could it be that Virtualdub is counting the wait cycles from the I/O thread? Otherwise, I'm assuming that as service packs have been added to the OS over the years, the overhead of communicating with the capture drivers and I/O subsystem might have been affected.

[NJRoadfan]

They used to seem SO fast, too. Flash and Javascript seem to be picking up where Windows left off in the area of forcing CPU upgrades.

The lack of "snappiness" (and the era of crap hardware in general) is why I completely avoided the P4/Athlon and kept my Pentium III plugging away during that time period. Intel manged to boost CPUs over 2Ghz but it didn't translate into any huge performance gains, just a lot more wasted heat and electricity (apparently a 1.7Ghz P4 finally outperformed a much slower P3, in real life use). I never saw the P4 as a compelling upgrade over what I had, I was simply used to huge performance gains upgrade after upgrade...and they simply weren't there. I know the NetBurst CPUs were great at video encoding, but I wasn't doing any of that at the time. Plus with the rash of bad caps on socket 478 boards and general flakiness, I stuck with a stable system. Socket A hardware was worse, so many dead boards and flaky chip sets...yuck.