VTDecoderXPCService CPU usage
SecuritySpy 4 is using less of my CPU… Maybe 50%.
However a new process popped up: VTDecoderXPCService
And that gets me to about 95% of what SecuritySpy 3 used.
Maybe this is the responsible party for all my problems.
jay
However a new process popped up: VTDecoderXPCService
And that gets me to about 95% of what SecuritySpy 3 used.
Maybe this is the responsible party for all my problems.
jay
Comments
SecuritySpy uses Apple's new API for video decoding (VideoToolbox), which does spawn this secondary process to do the actual work. So when comparing CPU usage from SecuritySpy v3 to v4, you need to take this into account: it's part of what SecuritySpy does. On many modern Macs this task will be hardware-accelerated, so will use vastly less CPU, otherwise the improvements will be more modest (but v4 should still be significantly more efficient).
The most useful figure to look at is the percentage shown as "Idle" in the bottom of the CPU section of Activity Monitor. This is for all processes on the Mac combined, normalised to 0-100% no matter how many CPU cores you have. If this is low (approaching zero), then your Mac is fully loaded and you should consider reducing the frame rates of your cameras. Also see the Optimising Performance section of the user manual for tips on how to reduce your CPU usage.
When I start SecuritySpy, with no viewing windows open and motion detection on, the system sits at around 30% idle, VTDecoderXPCService consumes the majority of CPU time. At some point in time (I haven't been able to sit and watch the CPU usage long enough to catch it), the system jumps to 0% idle, with VTDecoderXPCService consuming the majority of CPU. It never returns to the previous 30% idle state, until I restart SecuritySpy.
Any suggestions as to what to check for, or do I need to watch the CPU usage until the jump occurs, to figure out what is going on?
I have seen there are two VTDecodeXPCService child processes spawned by SecuritySpy, but only one of them is consuming CPU.
VTEncoderXPCService at about 40 percent (of one CPU)
VTDecoderXPCService at about 10 percent (of one CPU)
On a 2012 (4 codes, 8 threads) Mac Mini with 4 cameras running a total of about 75FPS, and a total load of around 13% "User" in Activity Monitor.
What are the specs on the machines that are having the problems?
If you have several different cameras, try disabling them one by one (or all of a particular model) to see if it can be isolated.
1. MacBook Pro early 2011, 2.3GHz Core i5, 4GB of memory
2. Mac Mini Mid 2010, 2.66GHZ Core 2 Duo, 8GB of memory
On the MacBook, idle CPU is initially at 50% and it slowly ramps up until after an hour it is showing 100% utilisation. Activity monitor claims I've got four cores available.
On the Mac Mini, CPU utilisation immediately jumps from 2% to 100%. I'm running this one headless with an HDMI "simulator" on it. Activity monitor claims I've got 2 cores available.
VTDecoderXPCService is using 26 threads and is a child process of SecuritySpy.
I am using motion detection and storing files on an external USB drive. I've just ordered an adapter cable to use thunderbolt instead, but as VTDecodeXPCService is using all the CPU, I don't think the external drive is the issue.
Any suggestions as to how to figure out what is causing this process to choke?
You don't need to install anything extra onto your Mac to enable it: it's just either there or not (depending on the graphics hardware because this is where the H.264 processing hardware is located).
From what I can gather (though Apple do not release information about this), most hardware can decompress one stream and compress one stream at any one time, and any additional streams will be processed in software.
If your Mac is performing hardware decompression on one of the camera's streams, what you will see if you enable the CPU column in the Camera Info window in SecuritySpy is that one of the cameras will be using much less CPU time than the other cameras. If you aren't seeing this then this indicates that you Mac doesn't have hardware H.264 capabilities.
As for unusual increases in the CPU usage of VTDecoderXPCService, we have had this reported by a few users, but we aren't sure what could be causing it. It certainly doesn't look like a bug in SecuritySpy (this is Apple's code). However, 100% CPU usage sounds reasonable for 5x 3 MP cameras running at 6 fps on the Macs that you mention (which aren't particularly powerful). Note that on your dual-core Mac mini, 100% usage for a process indicates only half of the CPU resources being used (the maximum, as reported by Activity Monitor, is 200% for dual-core machines). Perhaps it's simply your Macs being a bit under-powered for the job, in which case reducing the frame rates a bit would be the way to go.
I have two 1080p cameras at 10fps. VTDecoderXPCService is sitting at 112% CPU! I have to reboot the machine 2 or 3 times daily to cure this issue.
This triggers when I bring up the iOS app and try to browse the list of captured videos (like it is indexing or something). Never seems to complete after even hours and I have to manually kill the process to keep my server usable for other HA apps. Am never able to play the videos either.
Don't know when the problem started to show up, but every thing was working fine a few weeks ago. Can't correlate the start of the problem with any particular app or OS update as I was not paying detailed attention.
Will analyze a bit more later tomorrow when I have time.
I can't think of any reason that the number of threads would ramp up from 25 (I'm assuming that is a reasonable 5 threads per camera) to over 300. Suggests to me that threads aren't terminating correctly, somewhere. And these threads can't be idle, as the CPU ramps up as well.
I thought it may be related to viewing streams, but I turned off the server function and that didn't make any difference.
There could be an issue with certain streams being decoded by Apple's VTDecoderXPCService causing this issue.
So far all of the camera's I have access to don't show this increasing CPU usage issue. (3 different Foscam models, and a couple D-Link models that I have tested with)
I see exactly the same issue with my Mac mini 2012 quad core i7 model, 16GB
Running 6x 2mb Wansview cameras, each 10fps
I have to restart SS about 2-3 times a day, and no matter what I try it is still the same.
I have everything as it should be in the optimal performance setup. I have reduced frames rates to 10fps, and I get a slowly increasing demand on my system leaving me no choice but to restart SS, otherwise my Mac is unusable.
VTD starts at around 120% as soon as I restart SS, and ends up at 400+% with 0% remaining idle on the CPU.
I have a TV screen as the monitor, and some people have said that I am running it headless still, so no GPU is activated. But I cannot find proof that is the actually the case. The cpu usage in the camera info screen, shows camera usage ranging from 40% to 100%, but in no particular pattern, so for me its hard to tell.
I am probably pushing my system to the limit!
All I know is when I turn off SS (like right now) it's like using a new Mac again
Off topic (sort off), but does anyone know how SS performs against a good stand alone NVR unit for 16 channels running 2mp+ cameras? There seems to be very little info out there.
There may be a way to report it as an issue with Apple, but likely wouldn't be easy, nor quickly fixed, other possibility is to report it to Wansview, and see if they can resolve it (firmware update possibly)
Thanks for the response re different cameras, but I am convinced that is not the issue here.
As part of my home security business I have set these cameras up for many customers, some running at full 25fps via an iMac, and do not see the same issue with VTD or poor system performance. Even someone running 8 cameras on a 2012 iMac all 2mp, all running 15fps, full 24hr record + motion detection, no issues.
I am now sure it is simply a hardware performance issue with Mac mini's and SS.
PS..If I reduce my setup down to 4 cameras, I don't get the same issues.
I can only assume this issue is related to lower spec boxes?
are all cameras wired?
are the cables verified (either tester, or using something like iPerf to validate speeds & % of packets)
if all aren't wired, try temporarily disabling the wireless ones see if the issue still happens, if it doesn't flip which cameras are disabled.
actually breaking it down to sets of cameras even if all are wired could also be used to see if there is an issue with a particular camera(s) (which could be several things in the chain - camera hardware, firmware version, network cable, switch port)
maybe you've done this already.
I'll try and recreate this over the next couple of days.
Huge development on this subject.
I have been running SMC fan control on my Mac for ages and never even thought about it. I run it to keep the nosey fan quiet, limiting it to 3000 revs. This may worry many people, but the temp stays around 75° so I have never concerned myself, until last night, when we had a power cut for a few hrs, and once it came back on the SMC fan control needs to be reset, but I decided not to for a couple of hrs.
Well, I would never had guessed this, but with the fan on, running at about 5000 revs, the temp stays about 63°, and absolutely no issues with the system at all.
So it looks like keeping the core temp down below 65° is key!
VTD running at 46% cpu
kernel task, which is always on when I run SS now at 10%
Idle cpu 87%
System perfectly usable for other tasks
This is compared to my normal situation for past few months
VTD running 300%+
kernel task 300%+
idle cpu (obviously) 0%
System unusable
So to summarise:
6 cameras, 5 wired @ 10fps, 1 wireless @ 5fps, all 1080p 2mp recording 24hrs to ext HDD usb on Mac mini 2012 quad core i7 16GB
Running now for 8 hrs without issue!!!!! Idle CPU 87-90%
I also run SMC fan control to maintain a minimum 3300rpm (otherwise it does cycles of lower & higher rpm which is annoying at night) and frequently my temps are 70C or higher with no issues - this morning it's in the 71-75C range while I'm doing a few things before work.
with video encodes going on and the temp over 95C for an hour or more (either ripping or plex on-the-fly conversions to devices), still no issue with VTDecoder (the fan of course ramps up, but the sustained demand on all 4 cores/8 threads keeps it warm)
my VTDecoder has never spiralled out of control like you have seen, with the cameras I have: 5 wired, 1 wireless with strong signal, all Foscam, occasionally another wireless also with strong signal - D-Link