pi5 - motion not using hw acceleration to decode H264?

[JohnPaden]

pi5 - motionEye Version 0.43.1 - Motion Version 4.6.0 - OS Version Raspbian 12 - RTSP H.264 web cams attached via rtsp

it seems like ffmpeg could use the HW acceleration of the pi5

ffmpeg -decoders | grep -E 'v4l2|h264|h265|hevc' shows
V..... h263_v4l2m2m V4L2 mem2mem H.263 decoder wrapper (codec h263)
VFS..D h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
V..... h264_v4l2m2m V4L2 mem2mem H.264 decoder wrapper (codec h264)
VFS..D hevc HEVC (High Efficiency Video Coding)
V..... hevc_v4l2m2m V4L2 mem2mem HEVC decoder wrapper (codec hevc)
V..... mpeg1_v4l2m2m V4L2 mem2mem MPEG1 decoder wrapper (codec mpeg1video)
V..... mpeg2_v4l2m2m V4L2 mem2mem MPEG2 decoder wrapper (codec mpeg2video)
V..... mpeg4_v4l2m2m V4L2 mem2mem MPEG4 decoder wrapper (codec mpeg4)
V..... vc1_v4l2m2m V4L2 mem2mem VC1 decoder wrapper (codec vc1)
V..... vp8_v4l2m2m V4L2 mem2mem VP8 decoder wrapper (codec vp8)
V..... vp9_v4l2m2m V4L2 mem2mem VP9 decoder wrapper (codec vp9)

but the installed Motion v 4.6 is not compiled with HW acceleration - or at least does not have a switch.

a) is my configuration correct?
b) is there a way to increase the Speed of the System by switching on Pi5 hw acceleration to decode H264?

[MichaIng]

You mean for RPi DSI camera modules, or USB cameras?

motion itself is not responsible for decoding, but only FFmpeg is. H.264 V4L2 M2M should generally work if the respective modern KMS/DRM and codec stack is enabled (it is by default on RPi OS). When using RPi camera modules, motionEye needs to be started via libcamerify to detect them as V4L2 cameras, since motion does not support libcamera yet:

apt install -y libcamera-v4l2 libcamera-tools
sed -i 's|/usr/local/bin/meyectl|/usr/bin/libcamerify /usr/local/bin/meyectl|' /etc/systemd/system/motioneye.service
systemctl daemon-reload
systemctl restart motioneye

[JohnPaden]

Hello MichaIng, thanks again for caring, let me clarify.
The Pi5 is used as a motioneye 'server' serving network cameras via rtsp only.

Background for my question is that in the current one pi5 performs well enough for only 2 cams 1920x1080 or 2560x1920 with 20 fps, and motion eats up the majority of the CPU cycles.

Looks like in my config ffmpeg supports the hw acceleration, but motion does not?
And, btw, there are 10 motion entries in HTOP for 2 cams.

[MichaIng]

motion does no decoding. If it executes FFmpeg as deciated process, so motion alone is at 100%, then it is not decoding/encoding (actually encoding is the relevant step here), but some other parts of the process.

Still the question what type of cameras it is: USB, DSI, or does it relay netcams from elsewhere?

[Marijn0]

motion does no decoding. If it executes FFmpeg as deciated process, so motion alone is at 100%, then it is not decoding/encoding (actually encoding is the relevant step here), but some other parts of the process.

I think it depends a bit more on which Motion options are used.

Motion’s behavior depends on whether movie_passthrough and/or netcam_high_url are used:

https://motion-project.github.io/motion_config.html#movie_passthrough
https://motion-project.github.io/motion_config.html#netcam_high_url

Currently, in motionEye, the netcam_high_url stream option is not available in the GUI, but it can be set up using "Extra Options" under the "Video Device" section.

If you experience high CPU usage, it is recommended to use one of the passthrough options above. If a privacy mask or timestamp/text overlay is needed in the saved movie, and the camera provides those options, it may be better to use the camera's native settings so Motion does not have to process and re-encode the frames.

Regarding Raspberry Pi hardware acceleration: if I remember correctly, the Raspberry Pi 5 does not have dedicated hardware for H.264 encoding or decoding. It only has hardware decoding for HEVC/H.265. This means H.264 encoding on the Pi 5 is done in software, so it always uses the CPU.

AFAICS, the Raspberry Pi 4 is a bit different: it includes dedicated hardware support for H.264 decoding up to 1080p60 and H.264 encoding up to 1080p30. CPU usage can still increase if multiple cameras are used, of course.

I have read that the Pi 5 is still quite efficient at software H.264 encoding, but I am not fully sure about the details. When searching online, there seems to be a lot of conflicting information, and I do not own a Pi 5 myself, so I cannot confirm this directly. Please correct me if I am wrong on this.

EDIT: Maybe not that much. Based on these figures, it quickly adds up:

H264 1080p24 decode ~10–20% of CPU
H264 1080p60 decode ~50–60% of CPU
H264 1080p30 encode (from ISP) ~30–40% CPU

More info about hardware support:
https://www.raspberrypi.com/documentation/computers/processors.html

[MichaIng]

the Raspberry Pi 5 does not have dedicated hardware for H.264 encoding or decoding.

Ohh right, I mixed it up: It has a H.265 decoder, but neither H.264 decoder nor encoder. I just thought it was the other way round. Then it totally makes sense that transcoding or even just encoding of a local camera stream (if not emitted in H.264 already) eats a lot of CPU.

This was one of my major points of criticism against the RPi 5: Even if the CPU can manage a fluent 1080p H.264 stream, the high CPU load and heat emission this causes, in combination with only 4 equal CPU cores instead of making use of ARM's features to mix smaller and larger cores, ruled it out as production candidate for me. Using an RK3588 now in a passive full metal case which stays reliably below 40 °C, without any fan noise.

[JohnPaden]

very good insight.
So imho, the use case "pi5 with motioneye as a server to webcams with rtsp" is exactly what pi5 and motioneye design is for - just not with H.264? (AVC) but with H.265 (HEVC) ?!
So I will try to make all webcams use H.265 and motioneye store the movies as hevc(.mp4).
How to make sure that motioneye, motion and/or ffmpeg use the pi5 hardware in the most efficient way?

[JohnPaden]

I stopped the test. Only 25% of the videos in H265 are readable. I use .avi again.
What are you folks using?

[Marijn0]

I stopped the test. Only 25% of the videos in H265 are readable. I use .avi again.
What are you folks using?

Unfortunately I cannot help much without seeing debug-level logs.
Have you tried the movie_passthrough option?

[MichaIng]

exactly what pi5 and motioneye design is for

Obviously, the RPi 5 is not designed for video stream as much as the RPi 4 and earlier models were, with the design decision to drop the H.264 hardware codec. Also note that there is no (and never was) a H.265 encoder, just a decoder, which does not help you for streaming.

RPi engineers claim that the RPi 5 can decode H.264 faster in software than the RPi 4 could do with its hardware decoder: https://forums.raspberrypi.com/viewtopic.php?t=391283#p2334272
Not sure whether this is right, but of course it comes at the cost of CPU usage => energy consumption => heat emission => fan noise. And whether it can encode H.264 faster in software than the RPi 4 could do in hardware is again a different question.

motionEye and motion were both not designed to work with the RPi 5 and modern RPi libcamera stack, hence the libcamerify workaround. And there might be some subobtimal FFmpeg flag choices. But since libx264 (software codec) needs to be used on RPi 5 in any case, not much them could do wrong.