h264_v4l2m2m / bcm2835_v4l2 hardware accelerated decoding of h264 on kernel 6.6.63

[t3therdev]

Hi All,

We are trying to resolve an issue related to migrating the pi4/cm4 hardware from kernel 5.15 / ffmpeg 5.1.x where hardware decoding worked perfectly. To kernel 6.6.63/FFMPEG 7 (tested on mainline and your branch /test/7.1/main and /test/6.01/main). On the new kernel/ffmpeg hardware decoding specifically does not work and just hangs. If we remove the hardware decoding, encoding works perfectly.

v4l2-ctl returns the bcm encoder and decoder properly on /dev/video10 and /dev/video11

Source info is any h264 input (for example a usb camera with h264 video , or any rtsp stream with h264 video input. ) Lowing resolutions, fps , etc. doesn't seem to help.

For example, the following works on the older setup but does not on the newer kernel. removing the decode portion makes it work on the newer versions.

ffmpeg -f video4linux2 -c:v h264_v4l2m2m -input_format h264 -video_size 1280x720 -framerate 30 -i /dev/video0 -c:v h264_v4l2m2m -an -pix_fmt yuv420p -b:v 2048k -r 30 /test.mp4

(with -c:v h264_v4l2m2m removed)

ffmpeg -f video4linux2 -input_format h264 -video_size 1280x720 -framerate 30 -i /dev/video0 -c:v h264_v4l2m2m -an -pix_fmt yuv420p -b:v 2048k -r 30 /test.mp4

ffmpeg_debug_output.txt

on the boot/config/.txt we have gpu_mem=128 and have tried other settings as well with no success. falling back to the same exact configuration on the older kernel works perfectly.

[jc-kynesim]

What happens with ffmpeg 5.1.6 (current PiOS version) on the newer kernel?

[t3therdev]

hi @jc-kynesim mainline 5.1.4 and 5.1.6 exhibit the same issues.

we will give this a try as well: https://github.com/jc-kynesim/rpi-ffmpeg/tree/test/5.1.6/main

it does seem likes its a kernel level issue. are you able to do it on a pi4 on any of your builds?

[t3therdev]

As a quick follow up we tested on rpi 3 hardware and it has the same issue. So assuming kernel 6.6 related.

[jc-kynesim]

Seems odd - I'll have a look when I have a moment.

[6by9]

I've just posted on the duplicate - https://github.com/raspberrypi/linux/issues/6554#issuecomment-2557037733

Decoding of Big Buck Bunny works fine ffmpeg -c:v h264_v4l2m2m -i bbb_sunflower_1080p_60fps_normal.mp4 -an -pix_fmt yuv420p foo.yuv

Transcode of the 1080p60 version fails as ffmpeg doesn't set the level, and the default of 4.0 isn't sufficient for 1080p60. Use 720p60 clip and it's fine. ffmpeg -c:v h264_v4l2m2m -i Big_Buck_Bunny_720_10s_5MB.mp4 -c:v h264_v4l2m2m -an -pix_fmt yuv420p -b:v 2048k test.mp4 (file from https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/720/Big_Buck_Bunny_720_10s_5MB.mp4)

This is on a fresh install of Raspberry Pi OS Bookworm (19/11/2024), kernel 6.6.51+rpt-rpi-v8, ffmpeg version 5.1.6-0+deb12u1+rpt1, on a Pi4.

rpi-update to get 6.6.66, and still works fine.

I suspect we need a sample stream from your webcam.

[t3therdev]

@6by9 thanks for your feedback. We were able to confirm that hardware decode on the suggested file does work. Which is good news.

I have attached 2 sample raw captures from our usb camera that do not work. Hopefully this can provide some insight as to the issue and why it worked on kernel 5.15 but not 6.6.

output_samples.zip

[jc-kynesim]

Still odd. Your sample file plays fine for me just replacing the video capture bit of the command line with the capture file. Neither of the USB cameras I have here like the setup you are using (they don't want to output h264) so a direct comparison can't be done right now. This'll have to wait to the new year when I can scrounge a camera that looks a bit more like yours.

[t3therdev]

@jc-kynesim @6by9 thanks for your feedback. we have placed a stream on a temporary vps for testing. this rtsp stream with h264 source exhibits the same issue, so a usb camera is not necessarily needed.

Non working

ffmpeg -c:v h264_v4l2m2m -rtsp_transport tcp -i rtsp://199.127.61.234:9094/cam1 -c:v h264_v4l2m2m -pix_fmt yuv420p -b:v 2048k -an test.mp4

Removing the hw decode, and working

ffmpeg -rtsp_transport tcp -i rtsp://199.127.61.234:9094/cam1 -c:v h264_v4l2m2m -pix_fmt yuv420p -b:v 2048k -an test.mp4

[6by9]

Vanilla Raspberry Pi OS Bookworm install, although I have updated the kernel to 6.6.69 due to current development work. No significant changes to config.txt or cmdline.txt.

Hardware decode of that stream using ffmpeg -c:v h264_v4l2m2m -rtsp_transport tcp -i rtsp://199.127.61.234:9094/cam1 -an -pix_fmt yuv420p foo.yuv works fine.

ffmpeg -c:v h264_v4l2m2m -rtsp_transport tcp -i rtsp://199.127.61.234:9094/cam1 -c:v h264_v4l2m2m -pix_fmt yuv420p -b:v 2048k -an test.mp4 also works fine.

pi@pi:~ $ uname -a
Linux pi 6.6.69-v8+ #2 SMP PREEMPT Fri Jan  3 12:01:28 GMT 2025 aarch64 GNU/Linux
pi@pi:~ $ vcgencmd version
Aug 30 2024 19:17:39 
Copyright (c) 2012 Broadcom
version 2808975b80149bbfe86844655fe45c7de66fc078 (clean) (release) (start)
pi@pi:~ $ ffmpeg -version
ffmpeg version 5.1.6-0+deb12u1+rpt1 Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 12 (Debian 12.2.0-14)

Looking at your log in more detail, you have yuvj420p as the image format in places. AIUI That is full range yuv420 as used by JPEG, whereas H264 normally uses limited range. I wonder if ffmpeg is trying to convert all the images between the two ranges, and is therefore overloading a CPU, or just failing.

[t3therdev]

Hi @6by9 , so using your exact commands we still are not able to use the hardware decoder. removing the hardware decode reference does work. i think we were only using the yuv420p to feed the hardware encoder (which is working).

confirmed again the previous kernel that hardware decoding does work. there has to be something with this kernel / openwrt combination that we are missing.

Linux 6.6.63 #0 SMP Tue Dec 10 00:22:05 2024 aarch64 GNU/Linux

Sep 13 2024 15:58:42 Copyright (c) 2012 Broadcom version ddfba3e3c234500025b545512b4b214f28e453e9 (clean) (release) (start)

ffmpeg version 5.1.6 Copyright (c) 2000-2024 the FFmpeg developers built with gcc 13.3.0 (OpenWrt GCC 13.3.0 r28178-28de3ffefa)

I was able to confirm on bookworm standard release its working with the camera using:

Linux raspberrypi 6.6.51+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux

So the issue still is persisting on Openwrt / Rpi4 with even the latest kernel on 24.10 RC4.

[6by9]

I was able to confirm on bookworm standard release its working with the camera using:

Linux raspberrypi 6.6.51+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux

So the issue still is persisting on Openwrt / Rpi4 with even the latest kernel on 24.10 RC4.

Sorry, but if it is only an issue on some other distribution (first time you've actually stated that), then it's not something that we're likely to investigate.