SecuritySpy software on macmini server 85%cpu

[Data]

Hello all, i'm playing around with securityspy software and an axis hd ip cam,and i noticed that since i'm using it my mini server ( current version) is having the fans on pretty loud all the time now, so i went into activitymonitor and find that the securityspy software is using 85% cpu non stop even when the cam is idle ( i have it on motion detecting recording ).

So my question is, is anybody here also running the software and is this normal cpu usage ? Because if so ill have to look for some software that is not so heavy on the cpu and does the same.

Thanks for your info.

 

[Undecided]

Hello all, i'm playing around with securityspy software and an axis hd ip cam,and i noticed that since i'm using it my mini server ( current version) is having the fans on pretty loud all the time now, so i went into activitymonitor and find that the securityspy software is using 85% cpu non stop even when the cam is idle ( i have it on motion detecting recording ).

So my question is, is anybody here also running the software and is this normal cpu usage ? Because if so ill have to look for some software that is not so heavy on the cpu and does the same.

Thanks for your info.

I'm at about 10-20% with 4 cameras, including a low end Axis (all SD though) (2010 mini, Core 2 Duo at 2.66 Ghz). I think a lot of it hinges on what codec you select in the compression settings.

 

[Data]

Ok thats muck lower then mine then , but yeah my cam is 720p i think i have h264 as codec but not sure about that i have to check.

Ty for your reply, ill try it with diffrent codec and see what happens.

 

[Undecided]

Ok thats muck lower then mine then , but yeah my cam is 720p i think i have h264 as codec but not sure about that i have to check.

Ty for your reply, ill try it with diffrent codec and see what happens.

H.264 taxes the CPU. Switch to MPEG4.

One bummer is that I just got a camera that outputs H.264 video, so the compression is done on the camera, but sadly SecuritySpy doesn't support receiving an H.264 stream. So, the only option is Motion JPEG (for the stream that SecuritySpy receives).

 

[Data]

It seems it already is on mpeg4 ;-).

 

[Undecided]

It seems it already is on mpeg4 ;-).

Sorry there wasn't an easy fix. You might email the folks at Bensoftware - they're very responsive (note, though, that they are in the UK time zone).

 

[Undecided]

It seems it already is on mpeg4 ;-).

So with version 3.x of SecuritySpy, it supports MPEG4 and H264 streams. I changed the settings to tap into the MPEG4 streams on two cameras. Now, SS must decode the stream, and then re-encode it in whatever format you specified.

And so my processor usage is much higher, like 75% (compressing to MPEG4). But I don't know to what extent that is simply 3.x or having to decode MPEG4 streams.

I have Hazel & Automator re-compress high-bit recordings at night (if > 6 Mbit/sec, recompress to < 3 Mbit). As an experiment, I turned off compression in SS, and processor usage dropped to 41-57%. Still pretty high.

As another experiment, I selected JPEG compression, and the processor increased to somewhere in the middle, like 60-70%.

It seems like some efficiency was lost in going to 3.x.

Edit: And I'm accessing the two MPEG4 streams over RTSP. It seems like RTSP streams are more taxing.

So, compressed streams are taxing, RTSP instead of HTTP is taxing, compressing is taxing, frame rate is taxing. Each bit takes its toll.