Failed to decompress incoming video frame - Mac mini 2020 M1
  • I transitioned from a Mac Pro 2013 to a Mac mini 2020 due to the expected GPU gains, instead I'm getting a lot of "Error from camera "Front Door Camera", it will be closed. (Failed to decompress incoming video frame 22185,71042 Decompression failed) for all of my cameras. There are four wired and one wireless. On the Mac Pro I would only get the occasional "failed to decompress" error, and only on the wireless camera. The wired cameras and server are all on the same Netgear JGS516PE gigabit PoE switch. The exact configuration was copied from the Pro to the Mini via Time Machine, so no config changes. Any ideas?
  • I got the same error message with my Hikvision Camera on my MBA M1 with version 5.10 up to 5.3.1. On my intel MBP 2018 (Mojave) all versions run perfectly with my Hikvision Cam.

    My Dahua Cameras don't cause the bug (Failed to decompress incoming video frame 22185,71042 Decompression failed) only my Hikvision Cam does.

    My Settings are all the same on the MBP and M1 MBA (I'm using the Hikvision Profile)

    Maybe, does anyone know a workaround? Can I change some settings in the preferences for the Hikvision?

  • We've seen this problem specifically with Hikvision cameras and the M1 Macs. At this time we're not sure what the cause of the problem is, or if there is a workaround. We are investigating.

    @7RDR7 - are you using Hikvision cameras?
  • Getting the same issue. Hikvision camera as well. Also just switched to M1 MacMini. Other cameras (Reolink) are getting Excessive packet loss from network device. Was working perfectly on Intel iMac before switching.
  • Now getting the same error on my Reolink cameras
  • Getting this error with Annke cameras as well.
  • For any affected camera, please try this: in the Camera Info window, show the "Video Hardware Decode Status" column (click the header bar where you see the column names to show/hide the columns). The indicator should be "HW", indicating the decompression of video data is being done in hardware. Click the indicator and change it to "Software Decoder". Does this stop the errors?
  • Yes!! :-) Software Decoder" is working here with the Hikvision Camera! No more error message.
  • If I change from SW to HW back the error message (Failed to decompress incoming video frame...) comes back. Is this a SecuritySpy or Apple Hardware bug?
  • The CPU usage is around 23% -29% with SW decoding compared to 2%-3% with HW decoding. It okay for me :-)
  • Whats interesting: the picture quality with SW is a little bit better. Around 0,5 sec. after switching from HW to SW, the picture switches from a more "greyish look" to a clearer, brilliant look (with more contrast). It looks like a very light grey-filter is turned off with SW. It's very minimal but one can clearly see it.
  • Yes, all five cameras are Hikvision. I've changed to SW decoder and will report back.
  • Trading one error for another, and as others have noted, CPU utilization goes up from ~ 3% to ~ 20%, which isn't an issue except for it seems to be dropping packets now.

    Generated by SecuritySpy 5.3.1 running on the computer "Twin Island".

    Error communicating with network device "Front Door Camera". 5.3.1,10,835 Excessive packet loss from network device, the network may be too slow or defective, or this computer may be overloaded. Check the network and/or reduce this camera's frame rate.
  • Needed to go back to hardware decoding, software decoding was unusable, as the web access video windows were freezing, and lots of "computer overloaded" errors. Hope that the "decompress" error can be resolved....
    I'm running 4 cameras @ 2048x1536 and one @ 1536x2048 (doorbell), all at 20 fps.
  • Hi @Ben, if I wanted to call Apple to report this issue, how might I explain it? I'm still within my product return window.
  • So, I called Apple, and got bounced up a couple of levels. As you would expect, they did not believe that it was their issue, but did kindly explain the complexity of developing within an M1 GPU environment. It was explained to me in layman's terms that the M1 GPUs can require a bit of finesse by the application developers, "it's not as simple as routing a video stream to the GPU". It was their assessment that the GPU is being sent something it does not understand, meaning that there may be more software manipulation required prior to handing off to the GPU. Apple did confirm that my M1 Mac mini is running at a small fraction of its capabilities. Could it be a Hikvision idiosyncrasy, maybe, but that's beyond my diagnostic abilities, and Hikvision is the largest camera manufacturer. Hope it gets resolved...
  • What we'll need to do here is collect data about this problem from users, do some testing here to investigate possible causes, and open a technical support incident with Apple if necessary.

    At this point, since it's basically one brand of camera (Hikvision) that is having this problem with just hardware decoding on just the M1 Macs, it seems like a specific incompatibility with the two, and probably won't be something that we, as application developers, will be able to do anything about (SecuritySpy is basically getting the video data from the camera, repackaging it, and sending it to the Mac to decode via its hardware; if there were any bugs in this pipeline generally, they should be seen with other cameras and other Macs too).

    To this end, I have put together a debug version of SecuritySpy that will output some data (specifically, a sequence of video frames that provokes this error), that will help us to investigate this problem. For anyone having this specific issue, please do this:

    - Quit your existing version of SecuritySpy.

    - Download this debug version of SecuritySpy.

    - Right-click and select the Open option to open this debug version.

    - In the Finder, open the SecuritySpy folder that exists within your Home folder (Finder > Go menu > Home > SecuritySpy).

    - When SecuritySpy encounters a sequence of video frames that prompts an error from the Mac's decoding hardware, it will save this sequence as a file in a "GOV Captures" folder within the SecuritySpy folder. SecuritySpy will save a maximum of 3 of these files, which should have the names "" where X is a number.

    - Once you see that these files have been created, please email us these files.

    - Then quit this debug version and go back to your normal version of SecuritySpy.

    Please note that by sending us these files, we will be able to see a few seconds of video data from your camera(s). Please confirm in your email that you are happy for us to share this with Apple.
  • With the help of @7RDR7 I believe we have go to the bottom of this issue.

    Each video frame is constructed from multiple RTP packets that are sent over the network by the camera. Each RTP packet is numbered so that the receiver can detect packet loss in transmission. When this happens, SecuritySpy is meant to drop the affected frame(s), but this mechanism wasn’t occurring correctly - some incomplete frames were being let through, and under hardware decoding on the M1, this results in decode errors. Under software decode on the M1, and under any decode on Intel machines, this was simply resulting in partially-decoded frames and no errors, hence this issue specifically being associated with hardware decoding on the M1.

    This problem has now been rectified in the latest beta version of SecuritySpy (currently 5.3.2b10).

    However the root problem is in fact packet loss, which is due to camera and/or network issues. The new version of SecuritySpy should prevent the errors, but the unavoidable effect of this packet loss is short gaps/pauses in the live and recorded video footage when loss is detected.

    Use the Camera Info window to check the frequency of packet loss for your cameras (if you don't see this column, click the header bar where you see the column names for a menu that allows you to add it). If packet loss is occurring frequently, you should first check your network - ideally the cameras and your Mac should be connected together by a fast Ethernet network using a gigabit switch from a reputable manufacturer (e.g. Netgear, TP-Link) and high-quality Ethernet cabling. The next thing to do is to apply any camera firmware updates that are available from the manufacturer.
  • Thanks Ben for all of your support! As always, you guys are the best!

Howdy, Stranger!

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