Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-28T06:00:11.563Z
Answers.Text: 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.
Answers.UserDisplayName: Wayne Chen
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-28T11:30:15.360Z
Answers.Text: You're welcome. If you need anything else, let us know.
Answers.UserDisplayName: Dennis Mungai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-27T15:26:50.050Z
Answers.LastActivityDate: 2017-06-27T15:26:50.050Z
Answers.UserDisplayName: Dennis Mungai
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-26T04:29:50.160Z
Comments.Text: Video encoding will always take more *PU than copying a video. It's something else - network I/O maybe.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-26T04:35:23.113Z
Comments.Text: @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~
Comments.UserDisplayName: Wayne Chen
Tags: <video><codec><h.264>
Title: how to use h264_omx on RaspberryPi
UserDisplayName: Wayne Chen
ThreadText: # 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:
  [![enter image description here](https://i.sstatic.net/YRClP.png)](https://i.sstatic.net/YRClP.png)
  
  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.  
  
  ---
  
  