> The CPU will be *very* busy doing other stuff. It will need access to the > raw stream, so it will need to decompress, multiple times per frame (it's a > long story) so a compression algorithm with cheap decompression would be > great. I dont think you'll have enough ram bandwidth to go around decompressing and recompressing images in real time, even on a PIV if you use hand optimised PIV asm and prefetch instructions. > >(I did find that two 720x576 captures running together seemed to run into > >PCI bus contention.). > > My biggest concern is that the PCI bus won't cope with the bandwidth. That's > why I wanted hardware compression. But I'm always open to suggestions!!! Fair point. Without knowing what you are trying to achieve it is hard to comment. Typically a video app is designed to do all work on the same piece of data close together for cache efficiency. To avoid cache lines bouncing between CPU's its also not uncommon for different CPU's to work on different blocks of frames too. (you seem to have one board per cpu which is handy 8)) Your PCI limit on a good chipset for PCI 33Mhz is about 100Mbytes/second or so. That has to take both incoming streams, any frame buffer updates and any disk I/O outgoing. Its also horribly hard to get DDR SDRAM for PIV so you are looking at something like RAM 80x slower than L1 cache (hence the business about wanting to grab a piece of image once, process it entirely and then move on (and no you cant do that with mpeg))
