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

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

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

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

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

<p>That omits the video encoding phase, so see the new CPU load.</p>

<p>Next step, enable the video encoder but copy the audio stream intact:</p>

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

<p>Now, with that snippet, monitor the CPU load again.</p>

<p>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.</p>

<p>To see encoder options for the <code>h264_omx</code> encoder, run:</p>

<pre><code>ffmpeg -h encoder=h264_omx
</code></pre>

<p>And for the <code>aac</code> encoder:</p>

<pre><code>ffmpeg -h encoder=aac
</code></pre>

<p>Then tune the culprit with an acceptable preset and/or settings <em>until an acceptable compromise in quality vs CPU load is reached</em>. 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.</p>

<p>You can confirm this by running:</p>

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

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

CC BY-SA 3.0
2017-06-28T06:00:11.563Z
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
CC BY-SA 3.0
2017-06-28T11:30:15.360Z
You're welcome. If you need anything else, let us know.
Dennis Mungai
CC BY-SA 3.0
2017-06-27T15:26:50.050Z
2017-06-27T15:26:50.050Z
Dennis Mungai
<p>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:</p>

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

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

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

<p>so I use:</p>

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

<p>here is the output:
<a href="https://i.sstatic.net/YRClP.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/YRClP.png" alt="enter image description here"></a></p>

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

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

CC BY-SA 3.0
2017-06-26T04:29:50.160Z
Video encoding will always take more *PU than copying a video. It's something else - network I/O maybe.
Gyan
CC BY-SA 3.0
2017-06-26T04:35:23.113Z
@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
<video><codec><h.264>
how to use h264_omx on RaspberryPi
Wayne Chen
# how to use h264_omx on RaspberryPi

(Asked by: username_0 on 2017-06-26)

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?

**Tags:** video, codec, h.264

> **Comments:**
> **username_1**: Video encoding will always take more *PU than copying a video. It's something else - network I/O maybe.  
> **username_0**: @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~  

---

## 1 answers

### Answer by username_2 on 2017-06-27. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  
> **username_2**: You're welcome. If you need anything else, let us know.  

---

