Base M2 Tests
Comments
-
The hardware video decoding is primarily done in the Media Engine module in these chips, and this module seems to be the same in the M2 and the M2 Pro. So more GPU cores won't help with video decoding/encoding specifically. Instead, GPU cores provide more power for live video display, for example if you have a multi-monitor display with lots of live cameras being viewed frequently (a "video wall" kind of setup).
Extra CPU cores can be used to increase video decoding/encoding capacity, and the maximum number of cameras reported by the calculator is higher for the M2 Pro because of this extra CPU power.
For something like 16 cameras at 4K resolution, this can be easily handled by the Media Engine in hardware, so with a system of this size you'll see similar performance with an base M2 vs. an M2 Pro. But of course you may want to go for the M2 Pro for other reasons - as @schneideris points out, extra Thunderbolt ports and future proofing are good reasons, if budget allows.
But, don't skimp on the RAM as this is very important too! For this reason, if the basic M2 is more than powerful enough for your planned system without having to use software decoding, and you don't have a particularly complex live video display setup, then personally I would probably go for this with 24 GB RAM rather than an M2 Pro with 16 GB RAM.
-
I just replaced the M1 Mac mini we had running SecuritySpy with an M2 Pro Mac mini with 32GB memory and it is a world of difference. We had gradually been adding cameras and was starting to hit the limits of the M1. Now we have plenty of headroom for any additional cameras.
-
Picked up a Mac mini M2 Pro and indeed it is wicked fast. With just over 20 cameras feeding it with frame rates ranging from 12 to 30 and a mix of 2MP and 4MP resolutions, CPU is about 80% idle and GPU usage by VTdecoder is 28%.
Time to start playback in the SS Video Browser window is about 1/2 second as opposed to 5-6 seconds in my 12 Core Trashcan MacPro.
Only disappointment is SS still will not display 30 FPS from 4MP cameras. Only can muster 21-22 FPS. On 2MP cameras it can display about 28 FPS - almost full frame rate. That gives my "video wall" display have motion judder. Even with DELETING all but one camera from SS, it will never display frames any faster. This while CPU and GPU are barely being taxed. The judder is MUCH better than skips with my old Mac Pro, but this machine has untapped potential to do it smoothy.
Playback of the capture 30 FPS video files via VLC is smooth - and that is with SS running in background with all the cameras active. There is something in SS limiting display frame rate other than just CPU or GPU.
Overall, the Mac mini M2 Pro is a huge step up and a great value for its potential performance. It is scary quiet while running SS and all my cameras. Doesn't even warm up! I had considered trying just the plain M2 mini, but after spec of RAM and storage, it was just a few hundred more to move up to a M2 Pro
-
@brianwells and @guykuo , how is your network holding up with this throughput?
-
15 to 20 MB/sec here on a gigabit ethernet connection to Mac. Zero packet loss issues. It's only a fraction of the gigabit connection capacity. I'm on multi-gig for the non-camera LAN, but the Camera LAN is humming along just fine on its gigabit backbone with four POE switches. Wouldn't want to try this over a WiFi connection.
The MacMini M2 Pro just laughs at the data stream.
-
Hi @guykuo the slightly lower frame rate that you're describing I think comes down to how SecuritySpy handles the live video display. The video stream is clearly being received at 30fps (because this is what you see in the recordings), but the live display won't necessarily happen at this rate.
When SecuritySpy asks the GPU to display a video frame, there is a small but inevitable delay between the command being accepted and the frame actually being displayed, while the GPU does its work to prepare, queue and render the pixel data. If another video frame comes in before the previous one has finished being processed by the GPU, SecuritySpy will drop this second frame for display. When you have a 30fps stream coming over the network, not all frames will be equally spaced in time - some frames will arrive very soon after the previous frame, and these are likely to be omitted from the display.
The advantages of this mechanism are low latency and low memory usage. Plus, the problem becomes pronounced only at higher frame rates, and most users don't use such high frame rates - at something like 10fps, almost no frames will be dropped.
But, as you say, your GPU is barely being taxed, and it's a bit of shame that you aren't seeing the full 30fps in the live views. So, we'll consider adding an option of buffering frames for display, which would reduce dropped frames at the expensive of higher latency and memory usage.
-
Ben, thanks for the explanation of the mechanism. It would be awesome for the display pipeline become capable of 30 FPS on the faster machines. Moving some of my "beauty" and LPR cameras to 30 FPS were both big reasons for getting a faster machine. Majority of my cameras only got tweaked up from 10 to 12 FPS. The several doing 30 FPS captures are just so pretty and life-like when more smoothly played.
This Mac Mini M2 Pro performance beast has so much more potential to tap. I'd be smiling big if we could have a display frame buffering option. Obviously, it would not be viable on a slower machine, but these M2 Pro's are shocking fast and could take advantage of such a display option.
I can have Security Spy displaying 16 cameras while doing motion detection, continuous & motion capture of over 20 cameras WHILE VLC is smoothly playing a 4MP 30 FPS video in front of the SS' windows! The machine doesn't even feel laggy doing all that.
-
I agree that this would be a nice addition, so we've just added this to the beta version of SecuritySpy for testing (currently 5.5.8b13). You'll find a new option under Preferences > Display called "Use larger buffer for smoother live display". Please test and report back.
-
WOW! Holy Smokes, that was fast.......!!!!!
The larger buffer option is working wonders thus far. All display rates match the incoming frame rate. Still need some cars and pedestrian live activity to evaluate fully, but even the SS browser playback is smooth at 30 FPS. It doesn't even create a noticeable delay in startup of playback.
Having trouble finding a measurable bump in GPU usage. Weirdly memory usage by SS dropped in its graphs- maybe refilling still after app restart?
Thus far, looks to be a great improvement. Thank You.
-
Live feed is definitely improved for 30 FPS, but less monotonic than playback from recorded 30 FPS material. I think incoming delivery timing must vary, just as you alluded. Probably will need longer buffer to completely smooth out live material.
-
Just for completeness checking on the beta with larger video buffer option, I also tried it on my MacPro (12 core trashcan). It too was improved by that option. It was NOT anywhere near as monotonic as on the Mac mini M2Pro, but it was a substantial improvement for 30FPS playback. In my opinion, this is also worth trying if on a faster Intel Mac.
On an M2, this is going to be super nice if the buffer could hold just a few more frames (to improve live view monotonicity) before display. Even as already implemented in the 5.58b13 beta, it is already my preference if 30 FPS cameras are in the mix.
-
Great to hear this is a big improvement!
We're considering whether to keep this as an option, or to just make it the default behaviour without an option. The only issue is that on older Macs, if the GPU can't keep up, the buffer will always be full which will result in increased latency with little or no benefit in terms of frame rate. But I think this will be quite an uncommon situation - generally it's the CPU or decoding hardware that will get maxed out before the GPU. In any case, this will be a feature in the next update, whether there's an option to turn it on/off or not.
The option currently turns on a buffer with 3 frames. I don't think increasing this will help to reduce dropped frames. To check this, go to Preferences > Display > Customise and turn on both the "Incoming frame rate" and the "Display frame rate" options. Then you will see two fps figures in each camera's display (e.g. "30/30 fps"). If the second number (the display rate) matches the first (the incoming rate), then you can be satisfied that no frames are being dropped for the display.
Any difference you see in the live view vs. playback is probably down to the precise timing of the display of each frame, which is different in each case. For the live view, frames are being displayed as soon as possible when they are received. But, the timing of this depends on the flow of packets around the network, and you will get some frames that are closer together in time and some that are further apart. In contrast, when you play back a recorded movie, the timing of the frames is determined by the (usually very regular) timestamps that were provided by the camera and encoded into the file, so the spacing between frames will be much more consistent.
-
I would still be keen to trial a larger frame buffer of up to 15 frames (1/2) second. Whereas the live view display fps displays do match at 30/30, as you note, there is arrival time jitter for the live frames. Thus even with all frames getting displayed in time, there non-monotonicity in frame display.
With a longer buffer between arrival and display, there is more opportunity for judder to be hidden by the outgoing frames being "re-clocked." Assuming, of course, frames enter buffer upon arrival but are pulled out of buffer on an independent timer scheduled in SS. If the frame exiting is simply "immediately upon availability" then there would be no de-juddering.
I opine the large buffering should keep as an option with maybe an advanced adjustment to tune the buffer size. I realize it would be potentially deleterious if incorrectly set, but for those willing to tune it, there is potential for SS to de-judder the live display. Conceivably, SS could also monitor the drop frame rate and intelligently adjust buffer size, but that would be a bigger project - albeit an interesting one to code.
-
As a test, I've posted a new beta (b15) with a 15-frame buffer. I suspect that you'll see identical results to the 3-frame buffer, but please report back with your actual testing experience.
There is no de-juddering: frames are displayed as soon as possible, so any timing irregularities in the arrival of frames (a certain level of which is pretty much inevitable) will be seen in the actual display. However, at 30fps, this should not be very noticeable - the video should look nice and smooth overall.
What we'll probably do is have the 3-frame buffer option turned on by default, with an option to turn it off. I think this will work best in most cases. We'll consider further settings (variable buffer size, de-juddering) for the future, but I think with the addition of the buffer we've solved the main problem you were describing; any additional options will provide diminishing returns at the expensive of UI clutter and additional development work.
-
Tested with the 15-frame buffer on Mac mini M2Pro. Interestingly, live playback judder was worse than with the 3 frame buffer. I was surprised it wasn't identical or better, bur rather worse. Now that you confirm there is no re-clocking at the buffer output end, the lack of improved de-juddering is understandable. I didn't expect it to be worse.
Unfortunately, I updated via the debug menu version change. So I cannot verify by going back and forth between the 3 frame and 15 frame versions. I'm confident what I'm seeing is worse because it was about three times more frequent judder with 15-frame buffer. With 3 frames, there area long enough smooth motion segments that I can make out human gait impediments. With the 15 frame, the judders are too frequent to examine gait characteristics.
Lacking a re-clocked output end from the buffer, it seems 3-frames is better than 15 frames buffer for live display smoothness.
It is amazing that we have a Mac Mini, at 1/3 the cost of my 12 core Mac Pro, fast enough to make these possibilities thinkable.
-
After making comment about 12 core Mac Pro, I realized I still had a copy of the 3 frame beta on that machine. I've gone back to the 3 frame beta on the Mac Mini M2 Pro for verification. Awaiting some passers-by and cars.
EDIT: yes indeed, live display 30 FPS 4MP is worse with the 15 frame buffer than 3 frame buffer. It's not as stark as my first impression, but switching back and forth made it easier to see the difference.
-
I purchased a new Mac mini M2 16GB/500GB SSD in mid-July to replace my 2011 iMac 27 inch with 32GB/1TB HDD.
For the first time since I purchased Security Spy about five years ago, NO errors. 9 cameras (one unrecorded) are streaming at their set FPS. 2 8Mp, 2 4Mp and 5 2Mp cameras (SV3C, Sharx and Triu-Vision). 4 of the 2 Mp cameras are wi-fi. All working perfectly for the first time. Average CPU use 8%. One RAID 0 5.25 inch G-Technology drive and 2 OWC 5.25 inch drives connected by USB 3.0 backing up 4 other Macs using Time Machine. I also do my financials and church work on this Mac mini. No slow down or hiccups. This is one nice little computer. I just love Security Spy. Simple, easy to setup and use and powerful!
Running a 2 unit TP-Link X75 Mesh system with a wired backbone, a TP-Link CPE210 directional access point (wi-fi a mile away across the lake) for the 3 wifi cameras that are 150 feet away at lakeside and all GB POE switches.
Next step is to upgrade all of my 2 Mp cameras to 4K.
I just wish I could obtain camera licenses for 2 to 4 more cameras and not be forced to purchase another 8 when I would never use them here at the lake. Only so many things that I would record (or be allowed to by my wife).
-
Hi @JackS - great to hear that everything is running so smoothly on your new machine!
In regards to your comment about the licensing system, this has been discussed a few times, for example on this other forum discussion. Note that if we were to switch to a per-camera charging system, this would indeed work out cheaper for some customers but more expensive for others, and it would be unpredictable for our income and viability as a business. Under such a system, an 8-camera license and a 16-camera license would have to be more expensive than they are currently. So you can't really compare the current 16-camera license price with a hypothetical 12-camera price under a per-camera charging system; they will probably be more similar than you expect.
