Low framerate on Raspberry Pi W

[ashwinbangalore]

Hi All,
I've seen a couple of threads that talk about low framerate, but when asked for more debug information no further information was supplied. Well, I have the same issue and I have compiled the details that were requested earlier.

My setup is a Raspberry Pi W with the Pi camera V1.3.

• Build info:
  motionEye Version | 0.39.1
  Motion Version | 4.1.1
  motionEyeOS | 20180602

• Recording is H.264/OMX, recording only when motion is detected.

• Quality is set to 1200x800 at 25 fps.

• Fast Network streaming is Off.

I've noticed 100% CPU usage on the system (screenshot attached).
The Pi-W has heatsinks and is well ventilated. vcgencmd measure_temp reports temp between 60 and 70 degrees C.

Attached screenshots:
FFProbe output
top output
https://ibb.co/nma2pd
https://ibb.co/gckP2y

config and log files attached:
thread-1.conf: https://pastebin.com/K4RCF4Cw
motioneye.log: https://pastebin.com/9ux4wRK8
motion.log: https://pastebin.com/XmLxQm0K

Hope this information helps identify my low framerate issue.
Thanks for the awesome work on motionEyeOS and thank you for your time with this help.

Thanks.
BG.

[jasaw]

Pi Zero W is not fast enough to handle 1200x800 @ 25 fps.
There are multiple reasons why the software is not as efficient as it should:

• Motion detection algorithm works on the full resolution which is slow. There are two ways to obtain low resolution just for motion detection:
  • Make use of the 2nd image capture buffer in the Pi GPU so we get full resolution and low resolution video streams out of the Pi Camera.
  • Scale the video down to a lower resolution in software, but we are adding one more step, so is this really going to be more efficient?
• Motion software does not use MMAL zero copy because I couldn't get it to work reliably. See ffmpeg 3.1 supports h264 hardware assist encoding #365 (comment). Zero copy is an efficient way of getting image from Pi Camera (GPU domain) to motion (CPU domain) then back to MMAL OMX (GPU domain) for video encoding without needing to copy the image in between steps.

How is raspivid able to handle 1280 x 800 @ 30 fps with CPU cycles to spare?
That is because raspivid does image capture and video encoding in GPU before getting the encoded video out to CPU.

If anyone wants to help improve it, please feel free to do so. I'm particularly interested in what else can be done to squeeze every last bit of performance out of the tiny Pi Zero W. :-)

[jasaw]

Try this Pi Zero W configuration:

• Resolution: 1280 x 720
• Frame rate: 20 fps
• No live-stream and close your web browser connection as it loads the CPU.

[ashwinbangalore]

Hi Jasaw,
Thanks so much for responding and for your recommendations.
I've set the parameters exactly like you've mentioned. Closed the browser and disabled streaming.
The CPU usage is a constant 70% now, with the process using most CPU being motion executable.
I've also blocked the camera to simulate no motion, but despite seeing a black/blank image the CPU usage is still 70%.
Ran a quick test of motion detection and ran ffprobe on the resultant mp4. Results are around the same or worse (frame rate is 1.54fps and bit rate is about 180kbps):
https://ibb.co/gv3PLJ

What is the recommended settings for motion detection? Somehow I can bring the CPU usage a little more and increase the video quality?

Also, with H.264/OMX the GPU is being used for sure, right?

Thank you!
-BG.

[ashwinbangalore]

I turned off still images and got a significant boost in video quality.
Frame rate is up to 12.7fps and bit rate is 2000 kbps.

[jasaw]

Yes, H.264/OMX uses the GPU to encode video, but also relies on the CPU to feed it with images. If GPU is staved because of a choked CPU or limited memory bandwidth, you're going to end up with low frame rate. I recommend watching the CPU usage when motion is triggered because it's the most CPU intensive at this time. Make sure you stay below 80% CPU usage at all times. Enabling features like light-switch detection, despeckle filter, drawing motion debug box, etc, also put more load on the CPU. You'll have to tune the config to get the right balance.

[ashwinbangalore]

Thank you. I'm playing around with the parameters and will pick the optimal one.

Thanks so much for your helpful suggestions and time.
-BG.