>>>Might be interesting to try.

Cool; lots to think about.

I'll start thinkin'

Scott.

I don't know much of anything about going into and out of standby mode, but I can talk knowledgeably about efficiency.

First you need to think about CPU load caused by the driver versus CPU load caused by AbelCam. Driver loading is NOT trivial. To see what I mean, go to the Performance tab in your Task Manager, hit View on the menubar, and make sure Show Kernal Time is checked on. Assuming you are only running AbelCam, you read the graph like this:

Area under the red line = driver.
Area under the green = total.
Difference between red & green = AbelCam.

You are half-right about why lowering input resolution dropped your CPU (scaling load). The other part of it is that you lowered driver load simply by reducing the size of the captured image. Note that the relationship between image size and computing power used is exponential - not just linear.

With that in mind...

Lowering input resolution reduces driver load a lot and AbelCam load a bit.

Lowering output resolution reduces AbelCam load significantly.

Turning off captions and overlays reduces AbelCam load a little bit.

Using - or not using - Flip and/or Rotate in AbelCam makes no measurable difference.

Reducing frame rate reduces both driver and AbelCam load. CPU saving is more or less linearly proportional to the reduction in frame rate. "More or less" because the drivers' frame rate is not continuously variable (typically it changes in steps of 5) so changing from 8 FPS to 6 FPS will probably not do anything, but changing from 6 FPS to 4 FPS will.

Increasing (yes, increasing) the Quality setting in AbelCam might lower CPU load a tiny bit (because AbelCam is doing less compression - maybe) but the images streaming out of AbelCam will be larger and thus eat more network bandwidth.

Bottom line - video capture and streaming is resource intensive. There always has to be a trade-off between efficiency, speed, size and quality...

Edited later to add: BTW, about the hard disk access... Today I unplugged all cams, shut down all apps, unplugged Ethernet, etc. to where there should not have been anything going on. Still saw some HDD action that registers on the LED but not in DiskMon. Hmmm. This could be 1) XP babbling for some unknown reason, 2) something to do with the PCI analog video capture cards that I did not remove, or 3) a really sneaky rootkit doing something evil (unlikely for a number of reasons).

Yes indeed.

I don't know if this would be adequate quality for your needs or not, but on my public site I run the cams at 320x240 (in & out) and 5 FPS. I have about twice the CPU horsepower as your P-4 but with those settings I idle at about 50% CPU with 10 cams running. With one web visitor connected, 65%. Additional concurrent visitors only add maybe 2% each.

My cam "mix", FWIW, is 4 Orbit AF (USB), 1 Pro9000 (USB), 2 Analog cams on PCI capture cards, and 3 Web Video (IP Cams) devices. One analog cam is 640x480 In, 320x240 Out (to implement fake PTZ) and all others are 320x240 in/out.



Yeah... I see something similar on another XP box here that isn't doing anything camera- or AbelCam-related. Maybe something to do with XP's delayed writes scheme.

I don't know offhand why AbelCam would want to hit the disk all the time while scaling images. Is your system low on RAM? Like maybe the swapfile is coming into play when AbelCam does a memory intensive operation like scaling those big images?

>>>Incidentally... if efficiency is your #1 priority you might want to consider getting an IP camera instead of using a USB cam.

I've been thinking about this for a while, for various reasons....efficiency, distance from CPU, moveability, etc...

In this case do you use the AC agent to accept the stream? Does PTZ still work?

Great.

Thanks.