[FFmpeg-user] Latency in UDP to HLS Conversion

[Moritz Barsnick]

On Fri, Aug 21, 2020 at 08:27:28 +0530, KRISHNAKUMAR N K wrote:
> Thanks for your reply. I have uploaded the complete, uncut console output
> to the below google drive. I didn't observe latency with one output. I
> haven't tried a test without the yadif filter.
>
> https://drive.google.com/file/d/1g9KHOV41BmwEA0X-Urjao7jSQpOmGhfS/view?usp=sharing

Wow, I'm happy that I for once didn't ask you to post to the list.

> From the above logs, I can see "Circular buffer overrun. Surviving due to
> overrun_nonfatal option" for the first time. I have started a new test with
> increasing the fifo_size and without the yadif filter. Please go through
> the above log file and let me know your observation. Thanks in Advance.

What I can see that while your encoding starts in real time, it drops
to slightly below:

frame=1033708 fps= 24 q=33.0 q=37.0 q=24.0 q=31.0 size=N/A time=11:29:08.45 bitrate=N/A dup=56 drop=0 speed=0.962x

A speed of 0.962x is not enough. You need to reach 1.0x. (You obviously
cannot reach more, because the incoming stream doesn't serve frames at
more than 1.0x.) The encoding began at 1.0x (slightly above, because it
was consuming buffer), but then dropped on overall average.

This explains the delay - ffmpeg is still encoding older stuff from 27
minutes ago! (I'm calculating that 716 minutes have elapsed, but only
689 minutes of material have been encoded.) That would also explain
buffer overruns - ffmpeg is buffering all that input data somewhere,
for later consumption.

(1033708 frames correspond to exactly 11h 29m at 25 fps, so the input
is most likely perfectly constant frame rate. Just to sanity-check the
numbers.)

You need to make your encoding faster. Use a faster CPU, spread it to
more cores. Or improve your encoding options.

First, clean up your options. This from your log:

> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 0, only the last option '-c:v libx264' will be used.
> Multiple -pix_fmt options specified for stream 0, only the last option '-pix_fmt yuv420p' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 1, only the last option '-c:a libfdk_aac' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 2, only the last option '-c:v libx264' will be used.
> Multiple -pix_fmt options specified for stream 2, only the last option '-pix_fmt yuv420p' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 3, only the last option '-c:a libfdk_aac' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 4, only the last option '-c:v libx264' will be used.
> Multiple -pix_fmt options specified for stream 4, only the last option '-pix_fmt yuv420p' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 5, only the last option '-c:a libfdk_aac' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 6, only the last option '-c:v libx264' will be used.
> Multiple -pix_fmt options specified for stream 6, only the last option '-pix_fmt yuv420p' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 7, only the last option '-c:a libfdk_aac' will be used.

and make sure that the "-preset fast" option is really applied for all
encodings. (You can check with a higher loglevel, I believe. Or ba
validating the x264 debug output.)

Choose "veryfast" to see if it encodes faster.

Drop one of the four output streams, to see if that reduces CPU load.

Those are the things I can come up with quickly.

Good luck,
tell us how it goes,
Moritz