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