[FFmpeg-user] Latency in UDP to HLS Conversion

[KRISHNAKUMAR N K]

On Fri, 21 Aug 2020 at 11:57, Moritz Barsnick <barsnick at gmx.net> wrote:

> 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.
>
>  Thanks for the clarifications, this really helps.


> 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.
>
> I have cleaned up the *Options *which were displayed in the logs, also i
verified the *-preset fast* from the debug log level. I ran the same ffmpeg
command on 2 different servers, one with *-preset fast* and the other one
with *-preset verfast*. There was an improvement but the playback latency
increases over time.


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

I have dropped the highline profile output and now the live feed has 3
bitrates and this works fine for more than 15hours. Adding a highline
profile is causing more load? How should I handle this? Do you have any
suggestions/recommendations?

>
> Those are the things I can come up with quickly.
>
> Good luck,
> tell us how it goes,
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".