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