'ffmpeg' fails on RPi-4B running Bullseye (32-bit)

General
1

I had to reflash the SD card for a RPi-4B when its SSD packed-up recently.
I decided to use Bullseye 32-bit but find that 'ffmpeg' (v4.3.6) produces an error in the command line when I try to record a video from a camera on my network.
Here's my simple test flow.
wednesday_ffmpeg

[{"id":"911feac958ad77b0","type":"tab","label":"Flow 20","disabled":false,"info":"","env":[]},{"id":"86872925ba194088","type":"function","z":"911feac958ad77b0","name":"Build ffmpeg command","func":"msg.payload = 'ffmpeg -y -i http://192.168.1.164:8081 -t 5 -c:v h264_omx -b:v 2M /home/pi/test.mp4';\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":380,"y":240,"wires":[["4e12c1dcd2464c89"]]},{"id":"4e12c1dcd2464c89","type":"exec","z":"911feac958ad77b0","command":"","addpay":"payload","append":"","useSpawn":"false","timer":"","winHide":false,"oldrc":false,"name":"","x":330,"y":300,"wires":[["9efce3ad8f082d8c"],["9efce3ad8f082d8c"],["9efce3ad8f082d8c"]]},{"id":"08d49f3cd12c410a","type":"inject","z":"911feac958ad77b0","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":180,"y":240,"wires":[["86872925ba194088"]]},{"id":"9efce3ad8f082d8c","type":"debug","z":"911feac958ad77b0","name":"debug 20","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":500,"y":300,"wires":[]}]

If I run the same test flow on a RPi-4B running Buster (32-bit) with 'ffmpeg' (v4.1.11) it works fine.

Any ideas as to how I can sort out this incompatibility (?) issue?

Note:
I've tried various ideas I found on the Internet with zero success so far.

2

Bullseye removed the ability for hardware encoding using the legacy MMAL/OMX stack.
try using h264_v4l2m2m instead (make sure you have enough vRAM)

Being apart of another project - this was a pain when bullseye landed

3

Still get an error even with your suggestion...

Command failed:  ffmpeg -y -i http://192.168.1.164:8081 -t 5 -c:v h264_v4l2m2m -b:v 2M /home/pi/test.mp4
ffmpeg version 4.3.6-0+deb11u1+rpt5 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 10 (Raspbian 10.2.1-6+rpi1)
4

Have you tried -c:v libx264
??

5

Mmm...

There is a build script I wrote that builds from source with all the components.
but a little intensive (but hey we like that right :wink:)

bash <(curl -sL https://raw.githubusercontent.com/NRCHKB/nrchkb-ffmpeg-build/2.0/build-debian.sh)

My build script builds ffmpeg 5+ with h264_v4l2m2m

before going down that route - maybe @kevingodell has insight?

Which is usually fine - but uses CPU time, the fact h264_omx is in use, would suggest this is to be avoided

6

Thanks Walter - that works without giving an error and produces a video.

I've edited the recording flow in HSS and can confirm it now performs the record function.

1 Like
7

Just be mindful this is a software encoder, so you might see a usage spike/heat on the die.

EDIT
Ah! but if doing a single file - It will be fine.

Sorry - thought you were transcoding camera streams

8

Hi Marcus,
Will your 'build' script work for Bullseye 32-bit ?

9

The situation were I'm using 'ffmpeg' is to capture a 5 or 10-sec stream from a camera (running Motion-Eye-OS) on my network and write it to a file.

This forms part of the HSS project.

10

It technically should do.

It builds FFMPEG from Source (5+)
and installs the dev libraries from the respective OS's repository (OR builds from source if not found)

Get a spare SD card to test it before going in :smile:

I mean I state on the read me 32/64 :sweat_smile:

Use Option 1, then 8 - Guided

11

OT
I moved away from MotionEyeOS because it appeared to me the project was longer being maintained, let alone new features being added. Even the RPi Zero 2 wasn't officially supported.

12

Thanks for the feedback - you didn't say which camera firmware you moved to?

13

A work in progress (isn't it always?).

Essentially I am using Picamera2 as the basis for some Python custom firmware running on RPi Zero 2. Included is Tensorflow Lite, as light and tight as I can make it. It's running headless so I have no need for fancy boxes around objects being displayed on a screen.

The outputs are POSTing detections to NR Server which will then send alarms and images to Telegram, email etc.

So far tests have gone well, although the RPi Zero 2 is running close to its throttling limit to produce a few frames per second, which is fine for what I want.

Cheers

14

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.