Motioneyeos: RPi 3 + motionEye = slow preview/recording fps

Created on 22 Mar 2016  Â·  76Comments  Â·  Source: ccrisan/motioneyeos

First of all, great job with motionEyeOS. Was excited to see this software available and bought a couple of RPi 3s.

Unfortunately, recording stutters (1-2fps) once motion is detected. This applies whether its on large or small resolution. While watching the stream, I get 10fps, but drops down to 2-3fps as soon as it detects motion.

A lot of you don't seem to be having this problem. I am using an RPi camera when I first purchased my Raspberry Pi Model B. Think it might have anything to do with that?

question

Most helpful comment

I think the general problem is not that the raspberry is too slow, but the way videos are handled is extremly inefficient. Typical motion detection software works like this:

  1. Demultiplex incoming camera stream (e.g., mp4 to h264)
  2. Decode video stream (h264 to raw images)
  3. Analyze raw images (Detect motion)
  4. If motion is detected, encode raw images to video stream (raw images -> h264)
  5. Multiplex video stream (h264 -> mp4)

The computationally expensive part is the encoding of the video, which in my opinion is completely unnecessary. Last year, I started prototyping my own motion detection software. Instead of encoding the video, I stored the incoming h264 frames in a ring buffer (2. from above). As soon as a motion was detected in step 3, I multiplexed the frames from the ring buffer to an mp4 video. By doing this, the encoding (4.) could be skipped completely.

There are two main disadvantages with my approach. First, no information can be added to the video, as only the incoming stream is stored (e.g., no frame can be drawn around a detected moving object). Second, my approach was only able to handle h264 streams (which was not a problem for me as my camera was a h264 stream). The major advantage is that this approach is super fast. I don't remember the exact numbers, but by bypassing the encoding of the video the raspberry pi 3 could easily handle at least two Full HD cameras @ 25 fps. So it is definitely possible to use the raspberry pi for motion detection at high resolutions (without having only 2 or 3 fps).

Unfortunately, I did not have a lot of time to continue with the project as I finished my PhD last year. Maybe I will pick it up again and put some prototype on github. Would be great if something like this could be integrated into motioneyeos.

All 76 comments

What fps setting have you configured? If you're using a relatively high fps, the video encoding process might be too much for the CPU.

It was set to ~20fps. I have adjusted to 10fps and res to 640x480. Am getting an average framerate of 2.5 now, which is an improvement from ~1.5. It's an improvement, but it's not usable at the moment. Any ideas?

I tried to use Fast Network Camera, but the stream never appears (constant spinner).

Please attach all of your log files. I'll take a look over them and see if I can spot anything fishy.

Attached are my logs.

motionEyeOS-logs.zip

I just got a RPI 3 today as well and when it starts recording, my FPS also plummets
even at 640 x 480 as well.

I've attached my logs.
logs.zip

It appears to be any sort of recording, even with still images it starts to lag horribly and the FPS drops to 1 or 2 as @perrychan experienced.

I watched the CPU usage during recording/image taking and it remains at a normal level of 30 - 40% and the I/O remains at 0% so it doesn't seem like the CPU isn't powerful enough at least?

Have the same problem as @perrychan!
Running RPi2

https://github.com/ccrisan/motioneyeos/issues/235

Could not upload my log files on github for some reason...
My logs

I'll take a look over this. I haven't yet managed to investigate the problem.

Having same issue with RPI3 as well. I'm new to MotionEyeOS so maybe I'm something wrong. When a person walks into the view, it is initially smooth video, but then looses several frames.

@CrazyEyesPete Exactly the same thing I get, it's perfectly smooth for a few seconds when something moves and then drops frames as well. It still does this even with motion disabled and continuous recording enabled, it drops the frames permanently in this mode of course.

Anyone able to find a temp solution to this, till this is fixed permanently?
I like motioneyeos but this makes it unusable :(

I'm hoping @ccrisan will be able to look over the logs soon.

I will be taking care of this issue in the following weeks. I'm currently terribly busy with some personal matters but I haven't abandoned this project :)

Same problem here, only much worse. RPI V2. FPS drops to 0.1 once motion is detected. System is unusable.

@perrychan , @ShacharWeis , @CrazyEyesPete , @zettam can I have your config files please? I cannot seem to reproduce the problem at all.

I deleted everything, was waiting for the fix. Sorry.
I do not remember changing the defaults though. It worked, with the mentioned problem.

I've deleted the system and am now installing Zoneminder. After 12 hours my dropbox folder was full of false triggers and blank images that say "unable to open video device". Motioneyeos has a lot of potential, but I don't have time to debug it.

@ccrisan , I am having the same issue with my RPi 3. It can easily maintain frame rates over 10 fps, even while detecting motion, as long as it is only streaming. As soon as I enable the saving of movies onto a Samba share on a network drive, the frame rate drops to around 1 fps when motion is detected.

Attached are my logs and what I think are the relevant config files.

motioneyefiles.zip

Let me know if you need anything else.

I'm happy to provide my config as well if you let me know where to find it.

@ShacharWeis I would not bother with zoneminder. I've tried it. It does the same thing, motion does (of course depends on what you're looking for) with a much complicated and needy setup process. It's old.

@zettam yeah, I found that out. Can't even get Zoneminder to run at all. I've given up and am now using an old android phone. Very sad. Do you have a good guide for setting up Motion?

@ShacharWeis motion is very easy to set up actually, did you check the online docs?
I got zoneminder running, it's not worth the effort really. Motion is much better, with the same capabilities (and a newer/better interface) with much cleaner setup.

@cuddylier you can find the log files under the Expert Settings menu.

@perrychan I already attached my log files earlier in this issue report, just found the config backup part under General.

@ccrisan my config files:
ConfigFiles.zip

Same problem, currently on a RPi 2 (Model B).

Is this bug only on MotionEyeOS or can switch to Motion untill the bug is fixed?

I haven't been able to establish what "the bug" is about. People complain about slow fps in general. I'll take a look over the log files but I doubt there's one single problem that covers everything users are complaining about here.

@ccrisan I dont know if this has something to do with the bug but read this thread.

They talk about ARMv6 and ARMv7. I dont know, maybe this has something to do with it.

I too am having the same issues. I don't see any spike in CPU load.

How are you guys monitoring CPU useage? I'm running the OS image and I don't see a way of seeing the CPU temp or load. Do I need to run it in Raspbian for that functionality?

I'm also having the same issue. I've uploaded some same video's here:
https://www.dropbox.com/s/k05uyybz5yq2nlk/stuttery.zip?dl=0

I get the same issue weather I'm running hi or low resolution, and 30 or 20 fps.
I get great video with Fast Network Camera enabled, but as I can't record this it does not help.

I'm running a Raspberry Pi 3, with the camera module 2.
My log files are here: https://www.dropbox.com/s/h4lrb325aa45kj3/motion_logs.zip?dl=0

Thanks, David.

@dmarkscouk unfortunately I'm afraid that's the best you can get with motionEyeOS. No hardware/accelerated encoding/decoding is performed by the motion daemon and therefore the performance is limited to what the CPU can offer.

A slow SD card may impact the performance as well, while saving videos to a network share could make matters even worse.

The reason why FNA is that fast is that it doesn't use the motion "backend" but rather makes use of the streamEye project to simply capture and stream the mjpeg frames without processing them in any way (hence the great performance).

I know this is not ideal and is probably not what most of you were hoping for when decided to try motionEye(OS) but this is what we have.

I use 7 FNA-enabled cameras based on RPI1 and a powerful central computer with 8 cores running Arch Linux + motionEye that acts as a DVR for the RPI1 cameras. I believe this is the best setup you can have with motionEye.

So would it not be a good idea to use a RPi 3 as a hub for 3x Foscam IP cameras? They are capable of 720p video.

I intend to offload the camera data from the Pi to a USB attached hard drive.

I really want to be able to use MotionEyeOS for this, but it won't recognize the Foscams for some reason.

Sent from my iPhone

On May 13, 2016, at 1:55 AM, Calin Crisan <[email protected]notifications@github.com> wrote:

@dmarkscoukhttps://github.com/dmarkscouk unfortunately I'm afraid that's the best you can get with motionEyeOS. No hardware/accelerated encoding/decoding is performed by the motion daemon and therefore the performance is limited to what the CPU can offer.

A slow SD card may impact the performance as well, while saving videos to a network share could make matters even worse.

The reason why FNA is that fast is that it doesn't use the motion "backend" but rather makes use of the streamEye project to simply capture and stream the mjpeg frames without processing them in any way (hence the great performance).

I know this is not ideal and is probably not what most of you were hoping for when decided to try motionEye(OS) but this is what we have.

I use 7 FNA-enabled cameras based on RPI1 and a powerful central computer with 8 cores running Arch Linux + motionEye that acts as a DVR for the RPI1 cameras. I believe this is the best setup you can have with motionEye.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com/ccrisan/motioneyeos/issues/227#issuecomment-218988064

@ccrisan are you saying that MotionEyeOS cannot achieve better than 1 fps on a RPi when recording video with the motion engine?

It can, but at lower resolutions. I remember recording 3-4 fps videos at 640x480 with RPi1.

That sucks then, not really usable :(

@cuddylier I totally agree. That's why I recommend using RPi1 devices just as fast network cameras. I myself have 8 of them (I just finished installing the 8th one today), all of them working in FNA mode. I use an Odroid XU4 running motionEye as a hub that performs all the motion detection, movie encoding, notifications and whatnot.

So - I've had some success setting the motion trigger to a low setting (it
almost seems like if the motion trigger stops - it stops recoding the
video). Ill export settings and examples later tonight.

On Wed, May 18, 2016 at 2:17 PM, cuddylier [email protected] wrote:

That sucks then, not really usable :(

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/ccrisan/motioneyeos/issues/227#issuecomment-220113333

Would it be possible to activate video recording using a physical motion sensor or ultrasonic distance sensor (I presume this would save CPU power, that could then be used to record video)? Recording video in HD is no problem when I use the standard raspivid function.

It seems to be odd, using Pi2 I can stream at 20fps once motion is detected and recording starts it drops to 0.8fps. When I check the video the first two seconds are at high frame-rate but after that fps drops :( so recorded video is no good.

I think motion performance could be improved by:

  • Using H.264 video encoding hardware acceleration (that I think the raspberry pi has, but it is not used by motion now)

and/or

  • Using threads/parallel programming, so that motion can use more that one core. The raspberry pi 3 has four cores, and one is used by motion today. I am thinking have a separate thread for video encoding and one for motion detection.

What do you think about that, @ccrisan?

I totally agree that motion could make use of the GPU-accelerated routines to encode h264 movies. I believe I saw some work in this direction, although I believe it was something related to ffmpeg and not motion itself. However, I am not willing to touch motion's source code so we'll need to use the motion version that we currently have.

There are ways to use an external ffmpeg command using the _extpipe_ motion option but things start to get complicated and I don't have the time to add that to the current UI and then deal with all the problems that will occur.

Very disappointing. :(

I had the choice between one of these Chinese "phone home" IP cameras and the Pi3+Motion solution and I did chose the last option. :/

Now I am stuck at 352x288 videos with 10fps instead of 1280x720/30fps as offered by these chinese IP cameras. :(

I'm okay with setting up MotionEye on a Linux machine and catching the FNA stream. Is there any way to secure the stream? Maybe my searches didn't turn up anything.

Hey ccrisan, would any of the Linux OS's work on the Odroid XU4 with motionEye? I'm looking at ubuntu server.

I have a question . I'm on raspberry PI 3 connect IP camera and watch the video broadcast but slow. You do not know the problem?

@ccrisan That's why I recommend using RPi1 devices just as fast network cameras. I myself have 8 of them (I just finished installing the 8th one today), all of them working in FNA mode. I use an Odroid XU4 running motionEye as a hub that performs all the motion detection, movie encoding, notifications and whatnot.

Casin, can you clarify how you have set-up motionEye on your Odroid XU4 to perform the motion detection and encoding of your 8 cameras while they are set-up as Fast Network Cameras on the Odroid XU4?

If I imitate your setup, I only have a fraction of the FNA camera options on the MotionEye Hub device, only general settings and no motion detection or encoding options....?

The way I read it, It is a very interesting set-up =)

FNC is not available on Odroid XU4. You'll have to enable it on your RPi-based cameras, and then add them as regular network cameras to the Odroid XU4 running regular motionEye or motionEyeOS.

@ccrisan You haven't seen any FPS issues using motioneyeos on your Odroid in this setup during recording of video?

I run my 9 cameras at 1024x768@10fps. Provided not all of them record motion at once, things are pretty smooth.

Ah, still not great then :( Not worth investing in such a system for achieving that for me sadly.

Since v3.1, ffmpeg offers built-in support for using the decoding/encoding capabilities of the Raspberry Pi (see for example here http://www.cnx-software.com/2016/06/29/ffmpeg-3-1-adds-support-for-openmax-encoding-on-raspberry-pi-va-api-h-264-h-265-encoding-and-more/). I am not familiar with motion or ffmpeg.. would it be possible to make use of that? E.g., ship motioneyeos with a newer version of ffmpeg and activate the hardware encoding via an option?

Here is a link with the options (At least I think they are the proper ones): http://stackoverflow.com/questions/40175644/ffmpeg-hardware-acceleration-on-raspberry-pi

Hello,

I'm running 3 IP Cam on RPi 1B.
Of course it's lagging a lot but i'd like to know what is the 0.3/0.0 fps that is displayed on the motioneyeOS web monitoring page ?

Just hover it with the mouse and you'll see a tooltip with details. It's basically streaming/capture fps.

Disable "Motion optimization" in "Video streaming" tab.

How are you guys monitoring CPU useage?

Using 'top' in ssh.

cuddylier wow thanks... so it is not when expert settings - Enable System Monitoring. there is some values displayed. first is temperature, last is some kind of a network speed, i don't know which and where though. but second is complete mistery, i was thinking it is cpu load, but wondering what units it is.

@shinji2009 it's the sysload and it's read from /proc/loadavg: https://github.com/ccrisan/motioneyeos/blob/master/board/raspberrypi/motioneye-modules/boardctl.py#L34

It's non-dimensional and possible values range from 0 to infinity. For a normal functioning, you should expect values from 0 to the number of cores.

@ccrisan wow thanks...
strange thing that i'm using rpi3 and never seen values more than 1.4. i did something wrong with installation or motioneyeos can't use 4 cores?

Unless you have more than one camera attached to your PI, it's very unlikely to see loads above e.g. 1.5. 1.5 can be seen as 100% of one core (the thread handling your camera) + 50% of another one (the rest of the processes that are usually less CPU intensive).

Adding a second camera will instruct motion to spawn a second thread to handle the new camera. As far as I know it can't leverage more than one CPU (read: more than one thread) per camera.

@ccrisan thank you. and what about third value? what speed is it?

The total (send + receive) network IO, in kilobytes per second.

@shinji2009 I'm sorry for confusing you, I knew about the monitoring overlay load value but I always check with top directly in ssh to see exactly what's going on (what each process is using) and the actual % although the load figure represents this somewhat.

@cuddylier it's ok i need to know this too) it's my first *nix expirience

@ccrisan thank you. it is almost â„–5 of roadmap

Guys if you are satisfied with the resolution please close the Issue. Thanks!

Hey, maybe this could/should be added to the device overway ?
I was expecting it to work with smooth 30FPS / FHD as well - maybe something to 'warn' people about ?
Furthermore - is there hardware that is capable of doing what we expect short of a dedicated server ?

Agreed with @DeastinY, This would've been nice to know before spending several hours on it. It's a shame too, seems like a good project. But thanks for it anyways!

@Sja91 Hardware accelerated video encoding is now supported on version 20171008 version and above, just make sure you choose OMX version of the movie format, like H264/OMX.
The original Raspberry Pi 1 should be able to handle 30 fps at 800 x 600 resolution. Raspberry Pi 2 & 3 will be able to handle higher resolution.

@jasaw Well this sounds promising! I tried googling around for this but I can't find anything on it. Would you mind explaining more? I'm not recording if that matters, just looking to stream video. But getting 2 fps

I think the general problem is not that the raspberry is too slow, but the way videos are handled is extremly inefficient. Typical motion detection software works like this:

  1. Demultiplex incoming camera stream (e.g., mp4 to h264)
  2. Decode video stream (h264 to raw images)
  3. Analyze raw images (Detect motion)
  4. If motion is detected, encode raw images to video stream (raw images -> h264)
  5. Multiplex video stream (h264 -> mp4)

The computationally expensive part is the encoding of the video, which in my opinion is completely unnecessary. Last year, I started prototyping my own motion detection software. Instead of encoding the video, I stored the incoming h264 frames in a ring buffer (2. from above). As soon as a motion was detected in step 3, I multiplexed the frames from the ring buffer to an mp4 video. By doing this, the encoding (4.) could be skipped completely.

There are two main disadvantages with my approach. First, no information can be added to the video, as only the incoming stream is stored (e.g., no frame can be drawn around a detected moving object). Second, my approach was only able to handle h264 streams (which was not a problem for me as my camera was a h264 stream). The major advantage is that this approach is super fast. I don't remember the exact numbers, but by bypassing the encoding of the video the raspberry pi 3 could easily handle at least two Full HD cameras @ 25 fps. So it is definitely possible to use the raspberry pi for motion detection at high resolutions (without having only 2 or 3 fps).

Unfortunately, I did not have a lot of time to continue with the project as I finished my PhD last year. Maybe I will pick it up again and put some prototype on github. Would be great if something like this could be integrated into motioneyeos.

Appart from selecting H264/OMX as active codec, is there anything to do to enable HW acceleration ?

smanschi very interesting. hope you will succeed. about first disadvantage: any info can be added to video using subtitles. like SRT. it is basically a plain text format, low storage and cpu usage, easy to generate.

wow gpu. maybe its time to move back to motioeyos

@smanschi Did you ever end up putting that code somewhere. What you've described appears to be the wonder cure for many of the performance issues of VMSs. It may be very beneficial to share this with the project in a new issue, even if so they can review and see what could be implemented, if you don't have time to contribute directly.

Your mentioned disadvantages are only for troubleshooting, in which the longer process can be used, in normal operations you don't use the boxes.

i have the same problem, which is the solution?

Disable "Motion optimization" in "Video streaming" tab solve the problem

Was this page helpful?
0 / 5 - 0 ratings