Skip to content

VTDecoderXPCService CPU usage

edited July 2016 in SecuritySpy
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.



  • Hi Jay,

    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).
  • On my 2009 Mac, the VTDecoderXPCService is sucking up 80-88% of CPU. It makes the computer almost unusable.
  • Hi Bulent, this figure is the percentage of one CPU core that is being used by the process. So for example if you have a dual-core Mac there is still more than half the processing capacity free for other processes.

    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.
  • Bulent: In addition to the "Optimising Performance" section that Ben linked - check for things in the "Setup" option of camera configuration like "Text overlay" if thats on, turn it off, same as any "Transformations". Setup those on the camera itself - it greatly reduces CPU load as I found out (this new version of Security Spy will warn you when those are turned on)
  • I've checked that everything is optimized as recommended and I've turned my frame rate down to 6 fps.

    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.
  • I'm seeing:

    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?
  • It may be related to particular camera make/model and the video stream itself may have an issue that Apple's VTDecodeXPCService is choking on which causes the ramp up of CPU usage.
    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.
  • I'm running 5 HikVision 3MP cameras at 6 FPS. I've tried two different Macs
    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.
  • And within 30 minutes of my previous comment, I'm now seeing 100% CPU utilisation and over 50 threads for the VTDecoderXPCService process.

    Any suggestions as to how to figure out what is causing this process to choke?
  • I've read some information that VTDecoderXPCService is only meant to be used if there isn't a suitable hardware accelerated codec available. Has anyone been able to verify that and does this mean that I'm missing a "vital" codec from my systems? If so, does anyone know where to get the appropriate codec from?
  • Apple's TN2267 (OSX 10.6.3) states that "The availability of H.264 accelerated decode varies according to Mac model and Mac OS X version. Developers should always test for the availability of accelerated decode and have an alternative software decode path when hardware resources are not available". As we're now on 10.12, this information is old and has probably been superseded in later releases.
  • I turned on the SVC embedded stream option on all cameras and the system has been at around 43% idle for the past 3 hours. This is better than any other setting, so at this stage, I'm assuming that the substream has been created within the decoder service up until this point in time. Not sure what would be using that substream, when there are no camera views open on the system and the web server was not active. Turning on the server and connecting via the iOS app increased the CPU usage by 6% (43% idle to 37% idle).
  • Since 2012, most Macs (except the Mac Pro) have had hardware-accelerated H.264 processing. When it has to decompress or compress an H.264 stream, SecuritySpy will first ask the system for hardware resources, and if this is not available will fall back to software processing.

    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.
  • FWIW, I ran into similar issues on my 2012 Mac Mini. I tracked it down to a temperature issue. Cleaning all the vents and making it sure they were clean helped temporarily. My mac mini was throttling the CPU and slowing everything down. We eventually switched to an iMac.
  • edited April 2017
    I am seeing the same issues. Admittedly I am using a MacMini Mid 2011 2.5Ghz i5 with 4GB, but this machine isn't used for anything else, just SS. SO it should be enough.

    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.
  • Hi @gr4z when SecuritySpy starts to run after a reboot, and then 10 minutes or so after SecuritySpy has been running after a reboot, what is the CPU usage of the decoder service, as reported by Activity Monitor? How long does it take to get up to 112%?
  • Hi @Ben. It is currently sitting at 12% after the last reboot. It can take a few hours, sometimes (rarely) it lasts over 24 hours before it jumps up and the fans go mad. This usually occurs when I have viewed a stream on the SS website.
  • edited April 2017
    Seeing runaway CPU by this process also. In my case all cores go to saturation (0% idle and VTDecoderXPCService to 36X% on my mid-2011 Mac mini 2.3GHz i5 (with over 120 threads in that process).

    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 was wrong, it now takes several hours for the CPU to ramp up, but the number of threads consumed by VTDecoderXPCService climbs from an initial 25 to 300+! I switched to continuous recording, thinking there would be less h264 decoding if the camera streams were just "dumped" to disk, but exactly the same symptoms.

    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.
  • Anyone have any more suggestions to help with the all consuming VTDecoderXPCService service?
  • Are all of your cameras the same model or a mix of brands & models? If they are a mix, try disabling all of one type temporarily and see if that makes any difference (if no change, try one of another type) - or are any connected over wifi at longer range?
    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 have only 2 Wansview cameras, same make and model. That's it.
  • Hi guys
    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.
  • based on what you 2 have found, I'd recommend trying a different camera (Dahua, Foscam, Amcrest, on the more expensive end Axis) that others have verified as working well. It seems like there is an issue with the Wansview stream that VTDecoder is having issues with. (VTDecoder is an apple service, used by Security Spy to more efficiently decode the streams)
    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)
  • Hi
    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.
  • OK I have moved SS to another more recent MacMini (instead of mid 2011 4Gb, I now use a late 2012 16Gb memory machine). This machine now runs SS along with Plex and OSX Server and all is OK for the moment. I have not had any spikes in CPU at all.

    I can only assume this issue is related to lower spec boxes?
  • Repsolkid: thats great then, known reliable camera :)
    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.
  • We're using all wired Hikvision cameras. Last night, I did something, which I'll continue to try and recreate, and my CPU usage plummeted and the number of threads consumed dropped to 25. It soon ramped up again. All I can remember doing was check for SecuritySpy updates and check the App Store for any updates.

    I'll try and recreate this over the next couple of days.
  • Ok guys, morning
    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 would be surprised if this was related.

    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
Sign In or Register to comment.