Hi,
I'm using ZM 1.36.11 on bullseye 32bit (before with buster - no differences) and a raspi 4GB and 128GB sd card.
I have 2 720p cameras using ffmpeg and rtsp.
The cpu load avarage is about 1.4, memory usage 1.2GB and everything is working fine. Live view and recordings are fluent (live view in ZM is 1-3 seconds later - thats ok)
Now I'm planning to add a third camera, but currently the cameras are mostly at least 1080p
I tested 2 different 1080p cameras (rtsp) and I got a cpu average about 2, but there was a huge lag in live view for this camera (30-45 seconds).
Unfortunately I couldn't configure the rtsp stream very well with these test cameras.
Is this too much for the raspi? Or would e.g. using an USB SSD improve this?
Or shall I try to find a camera that I can configure to 720p?
Or can someone recommend a camera about 100Eur?
Can someone give me some tipps?
thank you
André
Question to Pi4b performance and camera resolution
-
- Posts: 1322
- Joined: Sat Aug 31, 2019 7:35 am
- Location: San Diego
Re: Question to Pi4b performance and camera resolution
You're right about cameras with 720 getting hard to find.
The biggest thing you can do is lower the frame rate...what fr are you using? 5-6 is all that's really needed, most of the time.
The biggest thing you can do is lower the frame rate...what fr are you using? 5-6 is all that's really needed, most of the time.
Re: Question to Pi4b performance and camera resolution
Try modect or mocord on a low res substream, and only passthrough and record on the 1080p stream.
It's also possible to use the high res stream for two monitors and just downscale the resolution in ZM by a factor of 1/2 (or 1/4, ideally you have something around 320x240) for the analysis stream. This doesn't use any CPU for zma, and works a treat. See below. To be clear I tested this in 1.34.
Notes:
monitor 39: high res stream, (1920x1080) put in zm as 320x240 (ffmpeg), modect.
monitor 40: high res stream, record
zma -m 39 uses very little ram even though the stream is originally 1920x1080.
Normally it would have CPU use such as in img htop3.
It appears that ffmpeg converts the video stream to 320x240 before analysis. (as both
ZMC processes are equally 7%).
It's also possible for some cameras (including this one) to have a low
res substream by default, which would lower zmc to <7% CPU. But here,
it's not necessary. For ARM boards it might be more useful.
Camera used is Axis p3905-r.
htop3 shows all ZMA processes. The max CPU used is near 30%. Easily
10x more CPU than monitor 39. Probably 20x. There is the cost of two zmc processes,
but the savings are still significant.
I will need to test this in 1.36... The ability
to use low res analysis streams in ZM from the high res stream means there's
no requirement for cameras to have two streams (although it
works better if they have them).
I would say that this configuration should be recommended for all new installs.
It will allow a computer to handle many more cameras. Including low power
ARM boards.
(Note that 1.36 should just have zmc, so you would have to compare those and not zma.)
It's also possible to use the high res stream for two monitors and just downscale the resolution in ZM by a factor of 1/2 (or 1/4, ideally you have something around 320x240) for the analysis stream. This doesn't use any CPU for zma, and works a treat. See below. To be clear I tested this in 1.34.
Notes:
monitor 39: high res stream, (1920x1080) put in zm as 320x240 (ffmpeg), modect.
monitor 40: high res stream, record
zma -m 39 uses very little ram even though the stream is originally 1920x1080.
Normally it would have CPU use such as in img htop3.
It appears that ffmpeg converts the video stream to 320x240 before analysis. (as both
ZMC processes are equally 7%).
It's also possible for some cameras (including this one) to have a low
res substream by default, which would lower zmc to <7% CPU. But here,
it's not necessary. For ARM boards it might be more useful.
Camera used is Axis p3905-r.
htop3 shows all ZMA processes. The max CPU used is near 30%. Easily
10x more CPU than monitor 39. Probably 20x. There is the cost of two zmc processes,
but the savings are still significant.
I will need to test this in 1.36... The ability
to use low res analysis streams in ZM from the high res stream means there's
no requirement for cameras to have two streams (although it
works better if they have them).
I would say that this configuration should be recommended for all new installs.
It will allow a computer to handle many more cameras. Including low power
ARM boards.
(Note that 1.36 should just have zmc, so you would have to compare those and not zma.)
- Attachments
-
- htop1.png (107 KiB) Viewed 11126 times
-
- htop2.png (175.72 KiB) Viewed 11126 times
-
- htop3.png (252.31 KiB) Viewed 11126 times
fastest way to test streams:
ffmpeg -i rtsp://<user>:<pass>@<ipaddress>:554/path ./output.mp4 (if terminal only)
ffplay rtsp://<user>:<pass>@<ipaddress>:554/path (gui)
find paths on ispydb or in zm hcl
If you are new to security software, read:
https://wiki.zoneminder.com/Dummies_Guide
ffmpeg -i rtsp://<user>:<pass>@<ipaddress>:554/path ./output.mp4 (if terminal only)
ffplay rtsp://<user>:<pass>@<ipaddress>:554/path (gui)
find paths on ispydb or in zm hcl
If you are new to security software, read:
https://wiki.zoneminder.com/Dummies_Guide
Re: Question to Pi4b performance and camera resolution
Thank you for your detailed reply.
Then I will try it with a 1080p camera and modect on low stream.
Currently the Reolink RLC-410W is available for a very good price.
Is it recommendable?
And would you say that I can stay with my 128GB sdcard (uhs3)?
The space is absolutely enough.
Then I will try it with a 1080p camera and modect on low stream.
Currently the Reolink RLC-410W is available for a very good price.
Is it recommendable?
And would you say that I can stay with my 128GB sdcard (uhs3)?
The space is absolutely enough.