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://w...@mail.com:test...@domain.com:8043/httppush/1/media_%v_%03d.ts -hls_flags delete_segments+independent_segments+discont_start https://w...@mail.com:test...@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 <barsn...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
