Skip to content

Version 5 and H.265

edited July 2019 in SecuritySpy
Because I can't help but upgrade when given the chance, I've already upgraded my home system using Axis m2026 mark II cameras. They do have H.265 video compression. But when I set them as such in SecuritySpy, I get some gnarly video artifacts (blinking grey/snow video) that makes it impossible to view the cameras. Anyone having similar issues or happen to have these particular cameras?

Comments

  • We haven't been able to test this particular camera model yet so there may be some issues with its H.265 video stream. I've replied to your email - hopefully we can work out what is going wrong here.
  • Thanks Ben, I just replied. Thanks for the quick help!
  • Ben, I've got several amcrest cams that have 265 support - when I turn this on in the camera settings, a grey box appears over half of the picture on each of the cameras. Switching back to 264 gives a regular normal image. Any ideas?
  • Startak11, in my case, reducing the frame rate in half 25/20 to 15/10 helped. Give that a whirl.
  • OK the Axis H.265 problem seems to have been due to high CPU usage and resolved by reducing the cameras' frame rates.

    However the Amcrest H.265 problem is a known issue whereby the camera seems to be producing data that cannot be decoded on macOS. At this point it looks like an Apple bug, and we have submitted a bug report to Apple - hopefully we'll hear back soon. For now you'll have to switch the camera to H.264 mode.
  • OK, thanks. Will there be notes in changes for future updates on whether this issue is fixed if/when that occurs?
  • I have the same cameras (Axis M2026-LE Mk II), and prior to v5 they would both reliably get 30 FPS, 24/7, for many years. Now one gets 20 FPS and other gets 27 FPS (like clockwork, they throttle down immediately). I'm on a iMac Pro with 8 cores and 64 GB ram. FPS is the same with h265 and h264.

    I factory reset the Axis cameras and installed the latest firmware, configured them back from scratch, then I removed the SecuritySpy preference files and connected both cameras back from scratch. Same thing, 20 FPS and 27 FPS. Let me know if there is anything else I can do to get it back to 30 FPS (I know it's not necessary, but I have lots of storage available and I prefer 30 FPS).
  • I think the key here is choice, we don't all have to rush to use h.265 on older hardware where H.264 is running perfectly. My main server runs older i5 processors, they have quicksync but no native h.265 acceleration, unlike my MacBook Pro. Ben, can you tell us which generation of Mac's are most appropriate to use H.265 compression on?
  • Dahua cameras are having the same issue with the grey screen with H.265. It is covering about ¾ of the the picture.

    Hope its the same bug as with Amcrest.
  • Jvss000, can you post your stream and image settings directly from the Axis camera webpage? I seem to remember some issues in prior versions that came due to exposure settings, if I remember correctly. But I can still get full 30 FPS from my 2025 Mk II's.
  • @jvss000 - this sounds very odd! The exposure settings mentioned by @laparrilla are definitely something to check. To see if this is a function of the SecuritySpy version, please obtain version from from the SecuritySpy previous versions page, and then compare them one after the other. Let me know what you find.

    @startak11 - at this point it looks like either an Apple or a Dahua bug. As it's not something that can be fixed in SecuritySpy, this won't appear in SecuritySpy's release notes when it has been resolved by either Apple or Dahua. But when there is any news on this issue I will post back to this thread.

    @paulgrimsley - according to Intel's datasheets, it's their 6th generation "Core" CPUs and later that can decode multiple H.265 streams in hardware. This includes most Macs from Late 2015 and later, with the exception of Mac Pros, which use Xeon CPUs. Xeon processors don't have the special "Quick Sync Video" module that does hardware-accelerated H.264/H.265 video encode/decode.
  • I did some more testing, factory reset the Axis cameras again and have found a repeatable way to view the drop in FPS:

    In Settings / General / Device, if Format is set to RTSP H.264 (video and audio) I will get 30 fps. If Format is set to H.265 (video and audio) it drops to 20 or 27, depending on how the Axis capture mode is setup (in short, it drops to 20 FPS if Axis is set to 16:9 max resolution, or 2688x1520, and 27 if set to 4:3 max resolution, or 2016x1512).

    To summarize, H.264 is 30 FPS, and H.265 is 20 FPS on this camera.
  • @jvss000, what kind of computer are you running? I found my 2015 i7 iMac struggled with doing a couple of H.265 cameras. I think that was right around the cut off for built-in h.265 encoding/decoding.
  • I think Ben has a point here, I think its an Apple problem with the OS. I don't think it the camera. I'm running a Sunba PTZ and a Dahua PTZ and have seen high CPU use (around 43%) when the H.265 decoding is taking place. Normally with the two cameras S.S. is using around 11% CPU with a late 2012 Mac Mini ("custom" with the 2.6 ghz i7).
  • @laparrilla 2018 iMac Pro 8-core, 64 GB ram. I'm going to put this issue on hold, as I also have 8 Axis M2026-LE Mk II cameras at a different location that are all running 30 FPS on H.265 on an iMac 4K 2017... So odd.
  • @jvss000 - H.265 does take more CPU resources to encode, so it would be understandable if a certain encoder would produce a lower frame rate when outputting H.265 vs. outputting H.264. However it's very strange that you are seeing different results from the same camera model! Perhaps this is a question for Axis - let us know if you find out anything useful from them.

    Certainly, if your Mac is not overloaded (check the "Idle" CPU value in Activity Monitor), SecuritySpy will be able to cope with incoming 30fps H.265 streams, and it won't be SecuritySpy that is limiting the frame rate.
  • As for decoding performance of H.264 vs. H.265, I have run some tests with a 4 MP Dahua camera running at 10fps and VBR encoding. This is with hardware acceleration turned off, so that we can compare the CPU-based decoding of the streams. CPU usage is quoted as per-core (not whole CPU) usage of the decoding task, as taken from activity Monitor.

    H.264 Baseline
    CPU usage: 19%
    Data rate: 670 KB/s

    H.264 Main
    CPU usage: 25%
    Data rate: 650 KB/s

    H.264 High
    CPU usage: 25%
    Data rate: 630 KB/s

    H.265
    CPU usage: 16%
    Data rate: 350 KB/s

    So, surprisingly, the H.265 stream uses the least CPU resources to decode. I'm not sure if this is representative of other cameras' streams as this is just one datapoint, but it is interesting and counterintuitive.

    As expected, the data rate for the H.265 stream is much lower - almost half that of the H.264 baseline stream.

    The other thing to note is that the H.264 Baseline stream takes less CPU to decode compared to the other H.264 profiles, for not much penalty in terms of data rate. The takeaway from this is that the Baseline profile is probably the best one to use in most cases.
  • Ben

    What Dahua camera did you test with?
    Did you need to change anything in the camera settings to get it to work?

    I have attempted to get H.265 to work with Dahua a few different models from 2MP to 6MP. They all show the same grey screen for ¾'s of the picture. Tried from 1 fps up to 20 fps.

    Any insight is greatly appreciate
  • BenBen
    edited July 2019
    This particular Dahua is a IPC-HDW4433C-A - no special settings were required, it just works. However it seems that some other Dahua models (including yours) produce H.265 video data that cannot be decoded via Apple's video frameworks on the Mac. Until there is a fix for this, you will need to switch your cameras to H.264 mode unfortunately.
  • Thanks for the info.

    Hope they update soon
  • @jvss000, what firmware are you running on your problematic cameras? I spoke too soon and now two of my Axis m2026 cameras are fluctuating, unable to hold a stable 25 FPS despite having plenty of idle CPU time from my Mini. I'm going to try and back track on firmware and see if that helps (it randomly has in the past).
Sign In or Register to comment.