Skip to content

VTDecoderXPCService CPU usage

124»

Comments

  • Conversely, Meatsuit, the two machines I'm running SS on, both identical machines (licence 4cam on on, demo on the other), were both on Ec and both had the issue.

    I say were as yesterday I updated the licenced machine to HS, and so far, 24hrs on, I'm yet to see the VTD problem!

    As they say.... Go figure!

    I do agree with you though that this is not an SS problem per se.
  • We've had a few reports now that upgrading to High Sierra fixes this issue - can anyone else confirm this?
  • Since updating one machine to HS I've not seen this issue again. Will be updating the other tomorrow. Hopefully, I've seen the last of it :-)
  • So is this issue fixed? There was a lot of chatter before this last update. I was thinking about upgrading to High Sierra. Wanted to wait till this issue was put to bed.
    Thanks
  • I am using High Sierra and the upgrade has definitely NOT solved the problem. The problem may not be due to SS but we are all having the problem when using SS.
  • Here's where we're at with this:

    VideoToolbox (VT) is the Apple API that SecuritySpy uses to decode incoming compressed data from IP cameras. For each application using VT for video decompression, VT spawns one separate process called VTDecoderXPCService, which does the actual processing.

    The main reason for using a separate process in this way is so that if the decoder crashes, it doesn't bring down the process that is using the decoder (in this case SecuritySpy). Video data can come from a variety of sources and may be of variable quality and integrity, so there is always a chance that a chunk of bad data can crash the decoder. When this happens, VTDecoderXPCService is designed to silently restart and continue processing.

    Unfortunately, something appears to be going wrong with VTDecoderXPCService in certain unknown circumstances, whereby with the same throughput of frames being decoded, its CPU usage goes up uncontrollably over time. Fortunately it is not affecting many users, but for those affected, it can be a significant problem.

    We haven't been able to reproduce the problem ourselves, which is really hampering our ability to investigate this, but we have investigated the problem on a customer's machine, and we have confirmed that the number of frames that SecuritySpy is sending to VT to be decoded remains constant while the CPU usage of VTDecoderXPCService steadily increases. If SecuritySpy subsequently stops sending frames to VT, CPU usage remains high. Periodically reinitialising each camera's decompression sequence with VT also does not prevent the problem.

    The problem seems internal to VT, and unfortunately nothing we have tried thus far has been effective. It doesn't help that this problem is so difficult for us to reproduce, and reports we have received about which Mac hardware and macOS versions are affected are inconsistent. So we have not been able to put together a demonstration to send to Apple to ask them to fix it.

    At this point, it seems that the only effective workaround is for SecuritySpy to detect this situation and completely restart the whole VTDecoderXPCService process. This is not ideal, as there will be a temporary gap in decoding services, and some frames will be lost, but it shouldn't be too disruptive, and it shouldn't be required very often.

    This has been implemented in the 4.2.4b3 beta version of SecuritySpy. Please can you all try this and report back about how this beta performs. Please make sure you are specifically using version 4.2.4b3, as we may subsequently remove this workaround if we find that it has undesirable side effects.
  • Ben, I have three identical in every way iMacs: Mid 2009 etc (can get you the exact model if required).

    These are all setup the same in terms of hardware, and almost the same in terms of software. I have three of these as they are dirt cheap to pick up 2nd hand (c.£150-200) and are still plenty powerful enough to run most modern stuff, and they're still supported with OS updates (most likely HS is the last though).

    Anyway, I tested SS on all three, and on all three the VT problem arose. On my newer iMacs it didn't.

    I updated one to HS and it solved the problem. On another machine I did try the suggestion you made on another thread about adding some software to kill/reboot VTDecoder, instead of updating the OS, but I couldn't get it to work, so just updated it. Again, problem solved. So I updated the third and also problem solved.

    I mention this because if you want to pick up a machine on which it seems likely you'll experience this issue, this model might be a contender. If you want the model number let me know and I'll dig it out (Can't get it now as the machines are not local to me, but I'll be there at some point this week).

    :-)
  • I have now upgraded 6 Macs to HS with SS setups and all have been fixed, and the VT use has vanished and cpu idle is down very low and all, the newer Macs 2017 i5, 3.1Ghz quads run 10+ cameras all 24 hr recording at a ridiculously low 4-6% cpu usage.
  • edited January 2018
    s
  • Ben, I found this tread as I too am experiencing high CPU. I wanted to try 4.2.4b3 to try and see if killing the process and restarting it would help but the link above takes me to beta version is 4.2.4b5 which i am not sure has that feature. Do you have a link for the correct beta? Thanks.
  • Hi @armakarma - the current beta (4.2.4b5) still has this tweak, so please test it and report back. Thanks.

    Note that it's not high CPU usage per se that's the problem here - high CPU usage could be completely normal depending on your setup. The problem here is CPU usage of VTDecoderXPCService that starts low, but that gradually increases over time all the way to 100%. Are you experiencing this?
  • Ok, here is my update.....I was experiencing high CPU of VTDecoderXPCService which went away when I upgraded to High Sierra. I then thought the problem came back as I was experiencing high CPU usage once again. I checked Activity monitor and though that the problem had somehow recurred but in fact this time in was VTENCODERXPCService (not decoder) that was through the roof. I realised that this must be due to the fact that I was displaying my cameras on 2 different iPads at the same time using the iOS App. Once I stopped using the apps to view, everything returned to a respectable level and performance has been great with no errors.

    Hope this helps.
  • Thanks for the update. High encoding CPU usage is expected with multiple viewing clients connected. You can mitigate this by switching the streaming format from H.264 to JPEG in the iOS clients (in the SecuritySpy iOS app settings), though this will use more network bandwidth (not a problem over a local network, but may provide slow performance over the Internet).
  • I've been mucking around with this myself as I've seen the issue cropping up for me.

    On my system, it looks like VTDecoderXPCService's high use of CPU is directly tied to motion detection and having the camera windows open (either on Mac or iOS devices)

    I'm running 5 Foscam cameras of varying types. The two with motion detection enabled are using ~9% CPU each.

    I had motion detection turned one for a third camera that was using 18% CPU by itself. I turned that off and CPU dropped to 0.0%

    I tested turning motion detection off with the other two, and voila, no CPU.

    Motion on for two cameras: http://take.ms/w9Luu
    Motion off: http://take.ms/rarseH

    That's with the Cameras window closed on my Mac. If I open it, all 5 shoot up considerably, which I suppose defeats the purpose of the software entirely (not being able to see the cameras).
  • Hi @mikejandreau - what you are reporting is completely normal. When SecuritySpy has to decompress the incoming video for any purpose - for example to display in video windows or to perform motion detection - it has to invoke the VTDecoderXPCService to do this task, and this uses CPU time. 9% per camera is very modest CPU usage, and note that this 9% represents the amount of usage of a single CPU core, so for example if your Mac has a 4-core CPU, then this 9% represents only about 2% of your Mac's total processing capacity.
  • Hi Ben, I've been running SS on an old OLD iMac at home for some time now, it's a 2006 running Lion, it runs fine on it. I swapped it to a slightly less old one yesterday, a 2007 running EC, and the VTDecode problem is there. I actually forgot about this having upgraded the work machines to Sierra (which solved the problem).

    So, back to EC: You mentioned up there a bit about a beta version of SS with a VTDecode killer thing built in, I'm guessing this never made it into the release version as Sierra fixed the issue?
  • Hi @steveb - what exactly are the symptoms you are seeing? High VTDecoderXPCService CPU usage isn't necessarily the sign of a problem, it could be a perfectly normal consequence of having to decode the incoming video from the cameras.

    What is the CPU usage of VTDecoderXPCService when you first open SecuritySpy (after all the cameras have opened and displaying live video)? Then, what is the CPU usage of VTDecoderXPCService after 12 hours or so of running? What are the exact specs of your iMac?
  • My VT experience may help so I'm sending it along plus I have a question.

    On a 2018 27" iMac, I'm running SS 4.2.9 with three cameras and my VTEncoderXPCService shows 0.0 % CPU. I only record motion detected files to a Capture Destination on my hard drive and FTP Uploads are not enabled.

    I also have a 2015 27" iMac and I installed a copy of SS for view only. When I launch the view only app, the main computer's VTEncoderXPCService jumps from 0% to 71% and on the remote computer the VTDecoderXPCService jumps from 0% to 15%. I imagine this is the expected usage for this setup. I've applied all of the optimization steps recommended in the manual.

    Both iMacs are running Sierra and have plenty of RAM plus SSD drives.

    If there is anything special to adjust when operating in the view only mode, I'm open to suggestions that might reduce the 70% CPU usage in view only mode is running on a remote Mac.
  • Hi @bg2003 this sounds perfectly normal. Adding a viewing instance will require the server to encode video to sent to the viewer, which is why you're seeing the encoder increase. The best way to reduce this CPU usage is to reduce the frame rate that the client requests (which can be done under Preferences -> Cameras -> Device on the viewing computer).

    However note that this 70% figure will be for one core of your server iMac, not its entire processing capacity. Check how many cores your iMac has by opening Activity Monitor and opening the "CPU Usage" window from the Window menu. It's probably 8 (8 virtual cores running on 4 physical cores), in which case a 70% usage for one process represents only a 9% usage of the iMac's overall processing capacity. So your current settings seem fine, and I don't think you need to take steps to reduce this usage.
  • Is it safe to assume the new 2019 iMac lineup continues to support hardware-accelerated video processing? When you read the specs, what is the main indicator that video processing is supported in hardware (rather than the CPU)?
  • BenBen
    edited March 2019
    According to reports, the new 2019 iMacs will use Intel's 8th-generation and 9th-generation "Core" CPUs. The specifications of these are described in Intel's document 8th and 9th Generation Intel Core Processor Families (Datasheet).

    The relevant technology here is called "QuickSync", which does hardware encoding and decoding of video data, and the document shows these two tables for decode and encode:

    image

    image

    So, these CPUs support the decoding of 16 simultaneous H.264/H.265 streams at up to 1080p (2 MP) in hardware via the QuickSync module. Unfortunately the specs don't say how many simultaneous decode streams are supported at higher resolutions, which would be useful information, with many users now moving to higher-resolution cameras.

    The encoding table indicates that this is for a single stream only - any additional encoding streams will be done by the actual CPU rather than the special QuickSync module.
  • edited October 2019
    VTDecoderXPCService is at 1,700+ percent. SecuritySpy cpu at around 175 percent, VTEncoder at like 250. Videos have bad artifacts and jerky. Right now I have 37 cameras, Grandstream and Trendnet from .9 to 4 MP all at 10 FPS. All on Motion sensing. All streams h.264. SS version 5.1.0. We are a school and principal wants them all on continuous through the day. I'm pretty sure our network wouldn't handle it. But are the artifacts and such from network saturation or server load being too high? Mac Pro Mid 2012, 2 x 2.4 6 core Xeon, 32 gigs RAM, Radeon HD 5770 1GB, SSD 10.13.6 system drive, 2 WD Purple 4TB drives in RAID0 for video storage. I'd like to get a tricked out new mac mini, but I don't want to spend that kind of money if it's not going to help. We will prob top out at around 50 cameras. Admin wants me to look into Verkada, but I want to stick with SS.
  • I think I may try change all cameras FPS to 5 FPS from 10 and change I frame interval to 20 and see if that helps CPU utilization and screen artifacts.
  • I dropped FPS to 5 and switched to continuous recording and my VTDecoder is down to about 80 percent CPU. That did the trick. No artifacts on screen. Server running much better.
  • Hi @mgisd - it sounds like your Mac Pro was simply not powerful enough for 37 cameras at 10fps - reducing the frame rate was definitely the right thing to do.

    A new fast Mac mini or iMac will probably perform better as it can decode up to 16 cameras in hardware, while your Mac Pro has to do everything in CPU. But you may decide that your current system works well at 5fps and you don't need to spend the money on new hardware.

    Keep an eye on the "Idle" percentage shown at the bottom left of the Activity Monitor CPU panel - this is the overall amount of the CPU that is spare. Ideally you don't want this to drop below 10%.
  • Idle is => 70% so I'm good there. Thanks, Ben.
  • That's great - plenty of headroom to add more cameras then. And/or you may like to increase the frame rates, just a little, in order to get more fluid video.
  • Hello This issue is still relevant.

    I got iMac 5K 2017 spec out.

    I have been using securityspy for quite some time now 1+ year.

    but after recent updates this issue is causing CPU to go crazy

    so fan spin up.

    so when I quit security spy it is all back to normal again. so something is wrong with this.

    I only have 2 cameras connected at the moment.


  • Hi @koburg that CPU usage is surprisingly high for just two cameras, but it's difficult to tell from the information you have provided what could be the cause. So that we can investigate this, please email us at support@bensoftware.com and include a debug file (SecuritySpy menu > Debug > Create Debug File On Desktop). We will then help you with this issue directly. Thanks.

  • Thanks sent

    case 55561

Sign In or Register to comment.