motioneye-project / motioneye

A web frontend for the motion daemon.
GNU General Public License v3.0
3.94k stars 649 forks source link

Realistic to have 4k security camera with Motioneye addon on a RPi 4B? #2433

Open wipeout666 opened 2 years ago

wipeout666 commented 2 years ago

Running HA core-2022.2.7 with Home Assistant OS on a RPi 4b (2GB ram, 5GHz quad core ARM Cortex-A72)

I have the addon motionEye 0.11.0 installed and this is being reported in the addon: motionEye Version 0.42.1 Motion Version 4.3.2 OS Version Linux 5.10.92-v7

I have a HikVision clone (namely Anpviz IPC-D383WD-S) that can render a 4k primary stream as well as a 480p secondary stream. My goal is to do motion detection using the 480p stream and perform a save on motion detect with a movie passtrough on the 4k H265 stream to my network attached storage on my router (SSD), all is wired gigabit.

I can connect both primary and secondary streams in home assistant. All is well when I have the primary stream set to 720p 5FPS; ram usage is 900MB/1870MB and CPU happily hovers around 30%.

However CPU usage and RAM usage is becoming sky high when I set the cam stream at 4k, no matter the frame rate. RAM usage is > 1500MB/1870MB and CPU is roughly maxed out at 90-95%. The video becomes lagged, and is behind real time the more the streams runs.

I have nothing enabled besides the “video device”; nothing is connected to the video in HA. “Video Streaming” is not enabled; so no re-coding is being done. “Motion detection” is not even activated at this point. There are no “overlay”, no recording being made at this moment.

Am I asking too much to the Pi ? I was under the impression the Pi could at least hardware decode the H265 stream, but it seems it is all done in software.

Is there anything I can do, besides forget the 4k stream and perform the motion detect/saving in 720p?

MichaIng commented 2 years ago

I also would have assumed that an RPi 4 is able to handle it. What I'm not sure about is whether there is transcoding and possible disk writes implied in cases.

Does it work when you watch the video stream from motion directly, in case after disabling any motion detection and upload in motionEye? Check the used ports via ss -tlpn.

Also check disk I/O to in case rule it out, and it would be interesting whether motion or motionEye utilise CPU and RAM, which can be checked e.g. via htop.

zagrim commented 2 years ago

My guess is that the issue is that to be able to serve the stream, the original 4K H265 stream needs to be decoded, and even though RPi 4B specs list "H.265 (4kp60 decode)" that doesn't help unless the process doing the decoding doesn't have built-in support for using the HW decoder. What I'm not sure of is whether ME relies on Motion to provide the source for streaming, or if ffmpeg is being used for that. But since the GUI receives JPEG frames for the stream, something needs to do decoding in the backend. And that process should be the one that hogs CPU on the device.

Anyway, I think the only remedy might then be to recompile Motion/ffmpeg with support for H265 HW decoder - if they happen to have support for that.

MichaIng commented 2 years ago

The Raspberry Pi APT repository ships an own FFmpeg build which should server hardware acceleration: https://archive.raspberrypi.org/debian/pool/main/f/ffmpeg/ But I'm whether Home Assistant OS uses this build as well, or an own with RPi hardware generation enabled.

Generally motion uses FFmpeg as well, motionEye uses it to generate previews and time-lapse movies, while the original MJPEG stream is taken from motion.

wipeout666 commented 2 years ago

I will try my best to give meaningful answers; bear with me if they are incomplete. Let me know

@MichaIng "htop" yields the following. Where can I find out the disk writes? image

@MichaIng I am not comfortable navigating in motion. I have accessed thru IP:7999, but I don't see the stream in motion directly. Why is that ? image image

MichaIng commented 2 years ago

Where can I find out the disk writes?

Via "Setup" (F2) > "Columns" you can add current per-process disk reads, writes and overall I/O to the list. But there are other tools as well, like iotop.

Interesting is that in htop doesn't show any particular process with such high CPU and RAM usage, but I realise now that it's the Home Assistant supervised container, right? So probably these stats can be better investigated on the host instead of withing the container.

Also I do not see motion or ffmpeg processes in the list, not sure how this is managed.

I see you added the camera as network camera and not as V4L2 camera. If it is directly attached to the RPi, isn't this possible differently (probably it is just the Docker host => guest network, and required like this?)? Passing a 4k stream ingoing and outgoing through network is quite some overhead. However, if the camera stream is available like that as RTSP stream, you could test this e.g. in VLC media player or similar to see whether it causes such high resource usage as well.

wipeout666 commented 2 years ago

@MichaIng The installation is Home Assistant Operating System with supervisor, so it is probably normal that all processes aren't shown. Key would be to SSH into the host, but I've never been able to activate it. It's been a few versions since my last try, I should give it another try; there's been a few versions upgrade between.

The cam is NOT directly attached to the Pi; so the 4k stream is thru the Pi's network. However, I don't believe the network traffic per say is a strain; the video probably a few megabytes /s ...?

Since I do not have access to the host by itself trying with VLC isn't so much an option. I'll be able to know more once I can SSH into the host

Stay tuned

MichaIng commented 2 years ago

If it is a network camera, can't you add the exact URL you use in motionEye in VLC as well?

I'm not sure whether network is the limiting factor, with 1 GiB Ethernet adapter on RPi 4, but depends on your Internet bandwidth as well. Note that when watching a camera stream on motionEye web interface, the stream is concurrently downloaded from the network camera, passed through motion and uploaded to your browser. Often upload bandwidth is quite limited, compared to download bandwidth, and often hitting one limit reduces the other streams bandwidth as well. However, if the client/browser is within your LAN, then of course it shouldn't matter.