[FFmpeg-user] Latency in UDP to HLS Conversion

[KRISHNAKUMAR N K]

Hi Barsnick

Thanks for your recommendation. 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
in latency in playback. Initially the speed was 1x, later it was reduced to
0.9xxx after a few hours. I have also reduced the* fifo_size* to *5000000*
[Earlier it was *10000000*] and i observed "*Circular buffer overrun.
Surviving due to overrun_nonfatal option*" on 24 CPU server and NOT
observing any error on 48 CPU server.

*On CPU load:* I did not observe any load on the servers and the load is
less than 10% on both the servers [one server has 24 cpu's and the other
one with 48 cpu's]

*At Present *: I am running the same ffmpeg commands with
*fifo_size = 10000000.*
*ffmpeg Command Used:*





*ffmpeg -i "udp://230.1.1.15:10000?fifo_size=5000000&overrun_nonfatal=1
<http://230.1.1.15:10000?fifo_size=5000000&overrun_nonfatal=1>"
-analyzeduration 25M -probesize 50M -threads 0 -vsync 1 -filter_complex
"[i:0xd49]yadif[vout];[vout]split=4[out0][out1][out2][out3];[out0]setdar=16/9[v0];[out1]setdar=16/9[v1];[out2]setdar=16/9[v2];[out3]setdar=16/9[v3];[i:0xd4a]aresample=async=1:min_hard_comp=0.100000:first_pts=0[aout];[aout]asplit=4[a0][a1][a2][a3]"
\-vcodec:v libx264 -s:v:0 256x144 -tune:v:0 film -r:v:0 25 -b:v:0 100000
-maxrate:v:0 100000 -minrate:v:0 100000 -bufsize:v:0 200000 -acodec:a
libfdk_aac -ar:0 48000 -b:a:0 48000 -sc_threshold 0 -pix_fmt yuv420p -flags
+global_header+cgop -profile:v:0 baseline -level:v:0 3.0 -preset veryfast
-nal-hrd cbr -keyint_min 50 -g 50 -map [v0] -map [a0] \-s:v:1 512x288
-tune:v:1 film -r:v:1 25 -b:v:1 200000 -maxrate:v:1 200000 -minrate:v:1
200000 -bufsize:v:1 400000 -ar:1 48000 -b:a:1 48000 -sc_threshold 0 -flags
+global_header+cgop -profile:v:1 baseline -level:v:1 3.0 -preset veryfast
-nal-hrd cbr -keyint_min 50 -g 50 -map [v1] -map [a1] \-s:v:2 640x360
-tune:v:2 film -r:v:2 25 -b:v:2 700000 -maxrate:v:2 700000 -minrate:v:2
700000 -bufsize:v:2 1400000 -ar:2 48000 -b:a:2 48000 -sc_threshold 0 -flags
+global_header+cgop -profile:v:2 main -level:v:2 3.1 -preset veryfast
-nal-hrd cbr -keyint_min 50 -g 50 -map [v2] -map [a2] \-s:v:3 1280x720
-tune:v:3 film -r:v:3 25 -b:v:3 1000000 -maxrate:v:3 1000000 -minrate:v:3
1000000 -bufsize:v:3 2000000 -ar:3 48000 -b:a:3 48000 -sc_threshold 0
-flags +global_header+cgop -profile:v:3 high -level:v:3 4.0 -preset
veryfast -nal-hrd cbr -keyint_min 50 -g 50 -map [v3] -map [a3] \-f hls
-var_stream_map "a:0,v:0,name:148k a:1,v:1,name:248k a:2,v:2,name:764k
a:3,v:3,name:1064k" -master_pl_name master.m3u8 -hls_list_size 3 -hls_time
6 -method PUT -ignore_io_errors 1 -hls_segment_filename
https://www@mail.com:test123@domain.com:8043/httppush/1/media_%v_%03d.ts
-hls_flags delete_segments+independent_segments+discont_start
https://www@mail.com:test123@domain.com:8043/httppush/1/playlist_%v.m3u8*

*Log Files for reference :*
*preset veryfast : *
https://drive.google.com/file/d/1738ELkQDelbPhlhPrJGiMdFLNj8bBZHi/view?usp=sharing
*preset fast : *
https://drive.google.com/file/d/1HcHR5Ye-lBjsIy2FIgsSlQl8vCqG3-xC/view?usp=sharing


Thanks

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