how to use h264_omx on RaspberryPi

Question

I'm using RaspberryPi 1gen B+, for push stream to web through rtmp. But I find my CPU usage came up to 90%+. This is how I use it:

ffmpeg -re -f concat -safe 0 -i playlist.txt -vcodec copy -acodec aac -f flv "rtmp://example.com:1060"

so I want to use the GPU for decode/encode. After google research, I found "h264_omx", and I've implement the h264_omx:

pi@pi:/usr/src/ffmpeg $ sudo ./configure --enable-omx --enable-omx-rpi
sudo make
sudo make install

so I use:

ffmpeg -re -f concat -safe 0 -i playlist.txt -vcodec h264_omx -acodec aac -f flv "rtmp://example.com:1060"

here is the output:

But the CPU usage still runs to 90%+, what's worse, the video become indistinct and only have 5fps.

so, what's wrong with me? Is it possible for 1gen B+ to hardware codec?

Answer 1

The first priority here is to determine the bottleneck, particularly on the encoding end first, then moving on elsewhere.

This is noted by the comment on the choppy video stream, indicating frame-skipping.

To do that, we need to isolate the task that takes up the heaviest CPU load.

Try running the FFmpeg snippet with audio encoding only, as you copy the video stream, then monitor CPU load:

ffmpeg -re -f concat -safe 0 -i playlist.txt -c:v copy -c:a aac -f flv "rtmp://example.com:1060"

That omits the video encoding phase, so see the new CPU load.

Next step, enable the video encoder but copy the audio stream intact:

ffmpeg -re -f concat -safe 0 -i playlist.txt -c:v h264_omx -c:a copy -f flv "rtmp://example.com:1060"

Now, with that snippet, monitor the CPU load again.

You're likely to observe that its' either workload (video or audio encoding) that takes up the larger share of the CPU load, and from there, you can then tune the encoder(s) as you see fit.

To see encoder options for the h264_omx encoder, run:

ffmpeg -h encoder=h264_omx

And for the aac encoder:

ffmpeg -h encoder=aac

Then tune the culprit with an acceptable preset and/or settings until an acceptable compromise in quality vs CPU load is reached. Note that some functions such as auto-inserted filters tend to run on the CPU, contributing to the heavy load on the encoder's end.

You can confirm this by running:

ffmpeg -loglevel debug -re -f concat -safe 0 -i playlist.txt -c:v h264_omx -c:a aac -f flv "rtmp://example.com:1060"

And monitoring the output. Learn what filters are being auto-inserted, and see if modifying the filter strings (via -vf) assists with the processor load.