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.

  • 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.
  • 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
  • Hi BrianM
    I give up. You are right, I have now had time to test SMC and slowly moved it back to 3000revs, and it has made no negative difference whatsoever.
    I have no idea what has suddenly changed now.

    I am now back to running everything as I was yesterday, yet the system has 90% idle, and no strain on the system at all.
    I am lost tbh.

    With the powercut, I had the system off for a few hours due to that which I never do. In fact I hardly ever restart the system, so unless something new has happened due to that power down, I am now at a total loss. But a happy one nonetheless :)

    Any ideas?

  • Hi BrianM
    Me again
    Ignore last message. I am definitely seeing a relationship between SMC and the cpu usage.
    I turned down to 3000 revs as last reported, and within 1hr the VTD was back to 300%+ and kernel was 200%+.
    I then took the fan up to 4000 revs and the VTD dropped back to 45%, and kernel dropped to 10%
    The fan was at 67°

    I can't tell you why, but I observed a definite connection.
    I am now at 4000revs on SMC, 67°, the idle on system is a fantastic 87%.
  • I have now removed smcfancontrol from my system, and I am constantly at 90% idle.
    Fan is louder, and running at an average of 5000 revs, temp approx 69°, but cpu usage is very low.

    I cannot explain it, but I don't care tbh, my system is perfect, I can use my Mac once again as if it was new, and yet I still run 6x 2mp cameras on full record on SS in the background.
  • Hmm, restarted Security Spy and watched the CPU go from 50% idle to 2% idle (majority of CPU burnt by VTD). Installed SMC and set to maximum fan speed, CPU temperature dropped from 90 to mid 80s. Idle was sitting around 3%.

    Exited SS, system dropped to 99% idle and CPU temp dropped to 44 (machine is sitting on top of an external cooling fan as well as the system fan). As soon as I started SS, CPU temp went up to 55, idle dropped to 50% and VTD consuming 200% CPU with 25 threads. Also turned screen brightness to minimum. Temperature seems to be stable at 70, CPU at 45-50% and VTD seems to be stable with 26 threads and 150% CPU!

    I'll have to keep monitoring to see if it slowly climbs through the day.
  • Spoke too soon. CPU usage has slowly climbed, but is currently stable at around 3-5% idle. CPU temp is at 90 and there are 41 VTD threads (25 on start up, slowly climbed over the last 50 minutes, but relatively stable now) and VTD is consuming 360% of CPU.
  • I've used gfxCardStatus to force either "internal" or "discrete" and things seem a lot more stable, when forced to use the "internal" GPU. Sitting at around 45% idle, temperature sitting around 70 and threads count for VTD isn't deviating from 25. It will take a couple of hours to verify, but looking good so far.
  • I'm having the same issue VTD is running 12 threads and % CPU >300. CPU Temp was well over 200 Deg F. I have a headless Macmini 6,2 i7 quad core w/16Gb of RAM. The fan is maxed out at 5500 rpm most of the time and only 40-50 % idle CPU

    I shutdown one of my six cameras. Somewhere I saw somebody added an OWC headless adapter, not sure why that'd have a thing to do with it, but I added it anyway. Today with 5 cameras and the adapter I'm running ~170 Deg F, still with 12 VDT threads, but % CPU is down to 80 (from 300), and the CPU is 75% idle. My fan is still maxed out to keep it that low [I use TG Pro fan control] Very weird, still at the high end of where I'd like to be given that SS is the ONLY APP running other than Plex & TimeMachine Server.
  • MikeM: what resolution are those cameras?
    The headless "adapter" makes the Mac think that a display is connected so the OS loads the drivers for the GPU (even integrated GPU still helps) - Security Spy can then use the GPU for one camera stream reducing CPU load. (also helps with Remote Desktop responsiveness)
    I find it interesting there are 12 VTD threads... and ChrisCam mentions 41. I have 1 VTD thread for my 4 H.264 cameras - uses about 20-23% of one CPU core. (my SD cameras use JPEG video instead of H.264)
    Are all of those VTD threads active? or are many showing 0% or 100% CPU? (could be crashed threads)
  • I know these are basics, but sometimes it turns out something basic is overlooked because we assume the basics were already correct. I just recently participated in a high pressure air compressor troubleshooting thread where we chased down all sorts of possible, complex issues only to discover the owner had not connect the end of the output hose to his tank. Super basic error, but we all assumed no one would have made so basic an omission.

    Let's make sure you have lightened Security Spy's work load.

    1. Is videodecode only when necessary selected in Security Spy preferences? It should be.

    2. For each camera's motion and continuous capture frame rate settings in SS exactly the same as the camera is delivering?

    3. Are you avoiding addition of any titling by SS? All titling and time marking in the videos should be done by the cameras, not SS.
  • Hi
    Removed the back off my Mac mini, now running 1800revs and not 5500revs, 90% cpu free, and my VT usage has dropped from 300%+ to 40%!

  • Wow. That was a LOT of thermal throttling. Maybe it is time to redo the CPU's thermal paste? I do that on my Mac laptops after about 4-5 years. By then, the factory paste is pretty badly dried up. Best to enlist a overclocking, geek friend if you have not previously done thermal compound application.
  • I've switched on continuous recording (5 minute blocks) and switched off motion detection. SS still starts off consuming 5 VTD threads per camera (each camera is encoding at 6FPS), I confirmed this by switching off one camera in SS and the thread count dropped by 5. Over the course of 12 hours the thread count has increased from 25 to 31 and the idle CPU from 42 to 24%. Switching the web server on and off doesn't impact the thread count at all.

    As far as I can tell, I've switched off every option that may require SS to decode video (and trigger VTD).

    I'm surprised that VTD is still being invoked when SS isn't doing any decoding or encoding (no cameras are being displayed).
  • One correction to make. Even though motion capture was switched off for each camera, I also turned off the Motion trigger "Video motion detection" each camera's setup screen and the VTD thread count dropped by one for each active camera (from 25 to 20). Not sure why this was consuming a thread when motion capture was already switched off!
  • Tried to edit my previous comment, but couldn't. Opening a window to display all cameras increased the thread count by 5 and the thread count didn't go down again when I closed the window (but CPU load did).
  • I'm running a Mac mini 2014 with 8 GB. 6 cameras, 5 of which are Foscam, 1 is D-Link.
    The Foscams running H264 require 75 KB/s each at 1280x760.
    The D-link running JPEG requires about 10x the bandwidth at 750 KB/s, 640 x 360.
    The VTDecoderXPCService uses 10 threads and 10% of the CPU.
    Generally CPU utilization is 75% idle.
    I gait on motion and send PNGs to email and record 10s movies.
    Performance is great. This thing actually paid for itself earlier this month.
  • On my Mac Mini (Core i5/ 2.5 Mid-2011), I have 4 wireless Sharx Security SCNC cameras. CPU is 40-50% idle, but VTDecoderXPCService uses 17 threads and 110-120% of the CPU. Also, when SecuritySpy is running, it takes 20-30 seconds to Remote Desktop to the Mac mini on my subnet. When SecuritySpy is closed, that connection is near-instantaneous. Something is not right.

    For further consideration - The cameras periodically throw SecuritySpy 22185,-8969 errors, yet are BULLETPROOF when connected to MobiLincCam. Doesn't it sound like a SecuritySpy/ Sierra 10.12.5 bug?
  • Restarted the system on 22 June, after making sure that every reference to motion detection was off (video motion detection is not selected in camera setup and motion detection is not enabled in motion detection). Continuous recording was set on, with 5 minute recording blocks.

    Since then everything has been stable with around 53% idle CPU. VTD is consuming 21 threads. If I use the app to view the cameras, the CPU idle drops around 10% and an additional 5 threads are consumed by VTD, but this goes away when I close the app.

    Looks like something to do with motion detection.
  • BUSTED (maybe)! Since my last post about two hours ago, I just attempted to connect to the Mac mini with Apple Remote Desktop. Lethargic 20-30 second connection, but when the desktop appeared, I had Activity Monitor at the front. VTDecoderXPCService was using zero CPU and zero threads. All cameras were disconnected, but started reconnecting just as the desktop appeared, and VTDecoderXPCService immediately returned to the 17-thread, 110% CPU usage I typically see.

    It appears something SecuritySpy does is crashing or overloading VTDecoderXPCService. Maybe motion detection like mentioned earlier. Unfortunately for me SecuritySpy is useless with out that feature.
  • s6275, just to be sure the basics are covered, you DO have a video dongle attached to the Mac Mini, right? Without something to force the video driver load, screen sharing will be extra sluggish getting started. I know there may also be an odd VTDecoderXPCService issue, but the video dongle is a required element for any headless MacMini

    Repsolkid's report makes the VTDecoderXPCService issue sound like a thermal overload causing CPU throttling and subsequent failed video decoding threads due to the CPU running too slow. Would be great if we had another user test if removing the back of the MacMini and doing additional cooling makes a difference.
  • Video dongle attached.

    Noticing today that some of my preferences appear to have been reset (?) after a recent update, I returned the frame rate settings on all 4 cameras to something more reasonable than what the gremlins had settled on. I managed to get VTDecoderXPCService into the 50-60% CPU range...but SecuritySpy is still disconnecting from my cameras every 10-20 minutes, with a nudge with Remote Desktop restoring the connections.

    Another component of all this is that at the same time this other business all started, I stopped being able to successfully load H.264 streams in the web interface.

Howdy, Stranger!

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