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: enter image description here

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?

  • Video encoding will always take more *PU than copying a video. It's something else - network I/O maybe.
    – Gyan
    Jun 26, 2017 at 4:29
  • @Mulvya the upload network is OK, I'v tested with my laptop to push steam to web, and it works fine. May it be I/O. Thanks~
    – Wayne Chen
    Jun 26, 2017 at 4:35

1 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.

  • Thanks for your help. I debuged yesterday with -an, the CPU usage lowed to normal.So the audio transcode is the key of my question.So I just to transcode audio to aac on PC, the trouble is gone.Thank you all the same.
    – Wayne Chen
    Jun 28, 2017 at 6:00
  • You're welcome. If you need anything else, let us know. Jun 28, 2017 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.