Low FPS on Raspberry Pi Zero W

[farleydwnsu]

I originally commented this on an issue someone else posted, but thought it would probably be best to post separately.

I have 2 USB cams setup, with one on a Raspberry Pi 3 and the other on a Raspberry Pi Zero w. They are both on Wi-Fi, and both configured with the same settings through the web interface. They are both set to 1280x720 30 fps in the video device settings and 10 fps in the movie settings. They are both on their respective 20180101 image. I have enabled prereleases in the expert settings. They are both using h.264/OMX encoding. I have also turned off all the services in the services section. The Pi3 works great and is showing around 10/10 fps in the overlay. The pi zero is showing around 4/1 fps in the overlay.

Is this to be expected when using a pi zero w? That fps seems low to me. I thought with the hardware acceleration being added that would go up. If I drop the resolution 640x480 on the pi zero it gets the fps up to about 7/6.

[jasaw]

I presume you're getting the frame rate from the web interface. That's the live video stream frame rate, which is different from recorded movie frame rate.
You're getting lower frame rate with Pi Zero W live stream because it's a single core CPU and live stream loads the CPU to 100%. Pi3 is a quad core, has lots of CPU cycles to spare, so you get higher live stream frame rate.

The hardware acceleration is only enabled for video encoding, i.e. recording movie. When encoding is offloaded to the GPU, all the Raspberry Pi models gives similar performance. The bottleneck is the memory bandwidth. That means Pi Zero W is also capable of recording movies at high frame rate, like 25 fps, depending on resolution.

[farleydwnsu]

I took a look at some of the videos that had been captured. They are looking like they are capturing a frame every 1-2 seconds. Any ideas on what I can do? For now I just have it set to the lower resolution and it is getting a higher fps. I will try swapping the cameras to isolate if the problem might be with the cam.

[farleydwnsu]

I swapped the cameras, and the pi zero is still getting the same fps with the other camera. Is there anymore info I can provide that might help, or any other ideas on what I can try?

[jasaw]

Do you know what video format you're getting from your USB cam? Is it H264?

[farleydwnsu]

The cameras I have are http://www.elpcctv.com/hd-ir-dome-720p-usb-camera-with-ir-cut-24pcs-ir-led-and-36mm-lens-p-202.html. What is hows on their site is 1280X720 MJPEG@ 30fps YUY2@10fps.

[fawick]

@farleydwnsu I have the 1080p version of that camera on a Raspberry Pi B+ and ran into similar problems . Since I believe the CPU of the B+ and the Zero W are comparable I chime in here.

I believe the motion daemon cannot produce the MJPEG frames much faster (even with motion-detection disabled, a s640x480 capture maxed out at 4-5fps for me), this is why I am looking into FFMPEG to generate a hardware-accelerated h264 stream here: #1259

@jasaw The ELP I have camera itself report this (and motioneye/motion selects the MJPEG stream on index0). I'd assume that @farleydwnsu would get the same info, except for the 1080p resolutions.

# v4l2-ctl --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
        Index       : 0
        Type        : Video Capture
        Pixel Format: 'MJPG' (compressed)
        Name        : Motion-JPEG
                Size: Discrete 1920x1080
                        Interval: Discrete 0.033s (30.000 fps)
                Size: Discrete 1280x720
                        Interval: Discrete 0.017s (60.000 fps)
                Size: Discrete 1024x768
                        Interval: Discrete 0.033s (30.000 fps)
                Size: Discrete 640x480
                        Interval: Discrete 0.008s (120.101 fps)
                Size: Discrete 800x600
                        Interval: Discrete 0.017s (60.000 fps)
                Size: Discrete 1280x1024
                        Interval: Discrete 0.033s (30.000 fps)
                Size: Discrete 320x240
                        Interval: Discrete 0.008s (120.101 fps)

        Index       : 1
        Type        : Video Capture
        Pixel Format: 'YUYV'
        Name        : YUYV 4:2:2
                Size: Discrete 1920x1080
                        Interval: Discrete 0.167s (6.000 fps)
                Size: Discrete 1280x720
                        Interval: Discrete 0.111s (9.000 fps)
                Size: Discrete 1024x768
                        Interval: Discrete 0.167s (6.000 fps)
                Size: Discrete 640x480
                        Interval: Discrete 0.033s (30.000 fps)
                Size: Discrete 800x600
                        Interval: Discrete 0.050s (20.000 fps)
                Size: Discrete 1280x1024
                        Interval: Discrete 0.167s (6.000 fps)
                Size: Discrete 320x240
                        Interval: Discrete 0.033s (30.000 fps)

[jasaw]

@fawick The issue that @farleydwnsu has is different from yours. The low frame rate MJPEG stream from motion is expected because that part is not hardware accelerated, but his hardware accelerated recorded video shows 0.5 fps, which suggests that the performance bottleneck is somewhere before video recording.

It could be as simply as the huge video traffic on the USB is chewing up all the CPU cycles.

[farleydwnsu]

Yes that is correct @jasaw and @fawick. The issue I have is with the captured videos not the stream. I actually have the streaminv turned off, as I have it set to email the pictures it captures. Let me know if there is any tinkering I should do any any additional info I can provide. I am really very pleased with this even with the choppy recording.

[fawick]

@jasaw

The issue that @farleydwnsu has is different from yours.

I'm not conviced that this is the entirely true. I'd conclude both issues have the same cause : Low capturing FPS. @farleydwnsu wrote that his stream rate is low, too:

The pi zero is showing around 4/1 fps in the overlay.

Even while the resulted video may have 30fps by its own right, the "perceived framerate" cannot be higher than the capture frame rate, can it? So I'd guess that if @farleydwnsu would show us an h.264 encoded video of that Pi Zero W that a media player would still report it to have a 30fps.

@farleydwnsu Would you kindly run ffprobe on your h.264 encoded video and paste the output, please?

[timdonovanuk]

I've always had this problem...I assumed the Pi simply cannot handle motion processing and recording at the same time. I get the same behaviour on a Pi 1 and Pi Zero.

[jasaw]

@farleydwnsu Have you run ffprobe on your recorded video files? What frame rate did it report?

Let's try to break this problem up into two parts (video input with motion detection, vs video recording):

1. Disable the video recording and image capture, but leave the motion detection on.
2. Close your browser connection to the motionEyeOS web interface (or simply close your web browser). This will stop motion from streaming.
3. Now you have motion software reading frames from camera, running motion detection and nothing else. Run top and watch the CPU load. If CPU load is pegged at 100%, it means your bottleneck is from camera to motion.

[rubyrrr]

@jasaw I am playing with my Zero W and V4L2 camera to see what gains in frame rate I can get. I am currently receiving ~6.5/3.3fps according to the live stream, 0.5fps saved as movie (having other issues there with repeating the first frame) or 1fps saved as stills to SD at 1280x720 75% quality with motion detection on and overclocked to 1000/turbo.

I have just tried your suggestion. I enabled SSH (previously all services disabled), disabled movies and stills and monitored top through SSH. With a browser stream open or closed CPU is at 100% with motion taking up ~98%.

Is this still indicative of a bottleneck between camera and motion?