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
  • 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.
  • 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.
  • 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.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!