CPU's, Which ones work the best for Video Capture, and how they preform under 98/NT.

[Phire]

I was just wondering.. Do CPUs with a higher cache amount make any difference in video capture? and also, I was wondering.. do Dual Processors work efficiently in 98SE, or MUST you have NT/2K installed? doing that would be a big problem for me.

[xevious]

You need NT/2k in order to be able to use dual processors. 9x/ME won't even recognize a second processor.

-Matt

[Flying dutchman]

The CPU is usually not the problem. A celeron 400 or equivalent does just fine. The following items, however, are VERY critical:

1 - You need a dedicated hard drive for capturing and one for the OS. Keep the dedicated video drive de-fragmented.

2 - Both hard drives should be operated under at least UDMA-33 (or UW SCSI)

3 - Your motherboard chipset should support UDMA (naturally) or you need the appropriate IDE or SCSI controller card.

4 - The Windows driver for the hard disk controller should OBEY if the capturing program tells it to disable "write-behind" caching (or else you'll drop tons of frames).

This is where the driver for the SIS 5591 chipset goes wrong. It always keeps the write cache enabled because that looks good on benchmarks.
I owned a Gigabyte SG-100 board once and had to sell it for this stupid reason. That was definitely the last time I've bought a motherboard without an Intel chipset.

5) you need an efficient chipset with fast
memory access. In my experience, the Intel BX chipset is the most reliable in the world for video capturing and it doesn't really matter if the cpu runs at 66 or 100 MHz bus speed. A Celeron does equally fine as a P-2 or P-3.

6 - 64 mb memory is the very least you need, 128 mb is better.

7 - the right sound card is VERY VERY important.

16-bit ISA soundcards with an accurate quartz such as the soundblaster 16 are very reliable, PCI soundcards such as the
SB-Live very often cause problems and may cause dropped frames. There are just too many bells and whistles in the Windows driver (3-d sound and such) and that costs valuable CPU time. I got rid of a Soundblaster 64 PCI for this very reason : I kept getting dropped frames. A Soundblaster 16 worked perfectly, though!
"El Cheapo" soundcards such as those based on the ESS1868 chip don't even have a quartz crystal on board- so don't expect audio and video to be even remotely lip-synchronous...

8- You need the right software (such as Avi_io) for capturing, and the correct driver version if you want to capture in YUY2 format. The current version of the Matrox Marvel videotools has broken YUY2 support....

[mynx]

You need a good amount of physical memory free. I had 128MB , but still had problems because must of it was being used. Even if I ctl+alt+del almost everything, It still showed over 75% physical memory in use.
It depends on what capture method you use. YUY2 requires a fast & powerful processor. Mjpeg hardware doesn't require nearly as must power.
I have had no problems with dropped frames using a SB Live sound card.
The bigger question is what do you want to do with the video. Changing the format, ie mpeg1 or mpeg2 encoding takes a lot of processor power.

[Phire]

Well I wanted to capture at full-frame res YUY2 in realtime. Then compress to MPEG-1 (not in real-time). Also, i've always wanted to know what advantages the ToasterNT has for capturing video.. it says it captures Uncompressed Video.. but doesn't any card have that capability?

[Grigory]

Hi,

1. Most capture cards do captures without using the CPU power. Even P166 can do YUY2 capture with only 20-30% CPU usage. This is because correct motherboard and operating system can transfer video data directly to the hard drive with minimum CPU load. You only have to take care about proper drivers and settings.

2. If you plan to capture with noncompressing card and use CPU to compress in realtime (not a bad idea for SIF size captures and for full size as well), then you need powerful CPU. The more MHz - the better.
3. For most video applications and tasks:
a) the L2 cache size is not important, because you have a lot of data. The difference in speed between cacheless Celeron 300 and PII 300 is 2-3% for most encoding/decoding operations.
b) Memory bus speed is not important in most cases - I found only 2-3% difference in performance for 124x2 = 250MHz and 50x5=250MHz for my old 266 PII with unlocked multipliers. That time I tested Xing and LSX MPEG encoding speed.
c) Dual CPU can be useful... sometimes. I do not know any software MJPEG or similar codecs that use two CPU's and can compress in realtime. All work is done on single CPU. However, using software comression you can set the "affinity" of capture application to only one CPU of two in Task Manager. This forces another one to work for all system tasks (serving hard drive operations, mouse, network,...) and this can increase system performance for realtime compression by 10%. Of course, you need NT 4 or Win2000 to use dual CPU's.
d) Dual CPU can increase encoding speed of MPEG: Panasonic and Tmpeg encoders use both processors effectively (double productivity), LSX uses second processor for all display tasks and calculation of "quality" while encoding, so the effect of second processor is up to 30% increase in encoding speed, or zero if turn all preview functions OFF. Cinemacraft (requires PIII or Athlon) encoder cannot utilize second CPU well (10% speed difference), but encodes at 2xrealtime on PIII 550 PC, full size mpeg2 vbr stream. For SIF size it works faster then realtime.
So, it is somewhat a question which setup is better: dual 600 or single 800 or 900; PIII/Celeron/Athlon.
For videoediting, not gaming, Celeron 566 with PIII core looks as cheap and working in most cases solution.
Old PII and celerons are less attractive because they have no support for SSE instructions. The example of Cinemacraft encoder shows that effective use of these instructions can speed up encoding by an order of magnitude. We can expect that newest applications can utilize these instructions too.
My future plan is to upgrade from ABIT BP6 dual Celeron 333(500) to X dual PIII 700, where X is some motherboard that does not exist now ;( .

256 MB RAM seems to be enough.
Software NT RAID I am using now works fine for YUY2 captures (uncompressed capture from Canopus DV Raptor analog channel) and does not take CPU power, so for video storage you need only enough connectors for drives, but not hardware RAID.
Most modern hard drives can work well for video capture.

Now questions:
Does anybody know the Athlon-based system performance for video applications:
1. Any known problems with Athlon motherboards and capture cards,
2. Compressors (MJPEG from Picvideo or Mainconcept) speed on Athlon vs PIII,
3. MPEG encoding speed on some popular encoders on Athlon vs PIII.

Any reply is highly appreciated.

Grigory

[jeffw]

If "write behind" should be disabled, then why is more RAM important?

I thought that the benefit of more RAM was that it allows for better cacheing of writing to disk to allow for a higher overall throughput. The write cacheing would smooth out any short-term throughput glitches such as thermal recalibration, seeking to a new cylinder, etc.

[Eric VanHeest]

-------------------------------------
If "write behind" should be disabled, then why is more RAM important?
-------------------------------------

Better video capturing utilities use their own buffers; RAM benefits this. Mostly the RAM is useful because it decreases page faults, and any page fault while capturing runs a good chance of dropping a frame while fiddling with the virtual memory.

[Flying dutchman]

A word of warning: Tweaking write-behind on the capturing drive should have no positive effect.

As I stated in my previous post, the capturing software can simnply tell the operating system to turn off write behind caching [I'm a programmer myself - it is just another parameter in the Windows/32 Createfile() command].
Therefore, in most "serious" capture programs the tweaking of write-behind should have no effect whatsoever - it is already disabled. Disabling it permanently will only slow down all your other applications!

[hippie91]

good to know