search

kemerelab / BehavioralVideo

4 stars 1 forks source link

CPU usage max out #5

Open daliu87 opened 10 years ago

daliu87 commented 10 years ago

The CPU usage is maxed out when camera is streaming. On occation it looks like a frame looses a few horizontal scans.

If run through GDB the frame artifacts are much more obvious.

ckemere commented 10 years ago

Please compare with the Flycap application...

daliu87 commented 10 years ago

Yea, looks like flycap hits about 80% usage and for a 52Hz 1280x960 mono-camera, can only render ~25Hz ish. I'm guessing it's an issue on the rendering/avlib/opengl side of things?

I branched the repo to work on these issues (just using the issue tracker for record keeping and as a bug tracker for myself)

ckemere commented 10 years ago

After the big rewrite I was looking at this today and it appears to me that the PointGrey Gig-E driver is starting up 2 threads (@12% CPU each) in addition to the main thread (@~30% CPU). I'm going to take another look at Aravis (an open source GigE player) to see if it is any better. Would also be good to check in Windows if you have that set up.

ckemere commented 10 years ago

Got Aravis to compile (had to hack the configure.ac file a bit). Comparing CPU at 30 fps, FlyCap2 is at 60%, whereas Aravis is only at 33%. Going to look into using that as an alternative source. Lots of GLIB dependencies, which is annoying.

daliu87 commented 10 years ago

As a hardware alternative, I'm looking into higher end AVT cameras with their drivers and also compressions using hardware acceleration as an alternative. Waiting for new parts to come in to test this.

ckemere commented 10 years ago

The USB 2.0 camera works great, btw (32% CPU).

ckemere commented 10 years ago

(Firefly MV)

ckemere commented 10 years ago

Delving into the aravis code, I think I understand something. The challenge with GigE is that the processor has to be concerned with split and potentially re-ordered packets. So the code has a bunch of stuff going on each time a packet is received before an image can actually be processed. Compare this with the USB version, where there is no reordering and the kernel driver takes care of assembly.

Maybe suggests the USB 2.0 version will be superior.

daliu87 commented 10 years ago

Just got around to compiling and testing Arvis (yea... deps were a pain and there's a bug in the make system). Looks like just reading the raw buffers at roughly ~50-60FPS takes up 30% CPU, but when it's rendered with a GTK viewer, it maxes out the CPU. Not sure if that's normal when rendering 1280x960 video at 50FPS?

I'll have to look into the networking code and genicam protocols. As far as I know, the gige vision protocol uses UDP, which is why you would have to reorder. But in practice over a dedicated route where lost packets/collisions are really unlikely, this shouldn't be an issue?