Hi Ico, I've run into exactly the same problem. Most probably it is the decoding of the firewire signal that eats the cpu cycles. The dv format (same as firewire) is compressed into a 29 Mbits/sec stream (see e.g. http://www.adamwilt.com/DV-FAQ-tech.html#DVformats) that needs to be unpacked before processing in GEM (or any other video software). My solution is to use analog video cameras with a capture card. In this way I am able to use four simultaneous cameras using less than half of the cpu power on a standard winpc with pentium 4, 3GHz. I don't need much picture quality so I got really cheap surveillance CCD cameras costing less than 50 euro each connected to a four-input capture card (about 190 euro). Another great thing is that your are not limited in cable length as with firewire. Another solution would be to find a firewire capture card with built-in decoder (I guess there are such cards out there). /Anders
Ivica Ico Bukvic wrote:
Hi all,
I've been trying to shave off precious cycles off the FW camera input capture. The problem is that vanilla capture of a FW camera feed (NTSC) already introduces 50+% of CPU overhead on an AMD64 3000+. I have experimented with lowered gem frame value, but anything below 20 seems to jagged.
So, here are the questions:
What is the cause of such a high capture overhead?
Is there a way to minimize such overhead beyond just optimizing code for sse and other similar methods, plus the aforesaid frame option for the gem object?
Many thanks!
Best wishes,
Ico
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list