[FFmpeg-user] Latency in UDP to HLS Conversion

[andrei ka]

hi,

a side note, afaik, hls spec advises: "...for broadest compatibility,
Variant Streams SHOULD contain the same encoded audio bitstream..." ;

&rei



On Mon, Aug 24, 2020 at 8:03 AM KRISHNAKUMAR N K <nk.krishnakumar at gmail.com>
wrote:

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