This means that the CPU remains free for other operations. I generally recommend to use CSI cameras with Raspberry Pi because they are directly captured by the GPU.
You can later add text, layers, or do any other process you wish. The stream is then received frame-by-frame in an OpenCV code. They key to achieve this is to do the h264 encoding on the RPi GPU (not CPU). But when it comes to real-time video streaming, you may find yourself lost in a bunch of long-reptile shell commands! In this post, I will give you some crystal clear instructions to receive a low-latency stream from a CSI or USB camera. Learn what filters are being auto-inserted, and see if modifying the filter strings (via -vf) assists with the processor load.Raspberry Pi boards are getting more and more widespread. 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://:1060"Īnd monitoring the output. 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. Then tune the culprit with an acceptable preset and/or settings until an acceptable compromise in quality vs CPU load is reached. To see encoder options for the h264_omx encoder, run: ffmpeg -h encoder=h264_omxĪnd for the aac encoder: ffmpeg -h encoder=aac 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. Now, with that snippet, monitor the CPU load again. 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://:1060" That omits the video encoding phase, so see the new 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://:1060" To do that, we need to isolate the task that takes up the heaviest CPU load. This is noted by the comment on the choppy video stream, indicating frame-skipping.
The first priority here is to determine the bottleneck, particularly on the encoding end first, then moving on elsewhere.
0 kommentar(er)
