Hi Barsnick As suggested, I have dropped one of the four output streams and the stream is going fine for more than 15hours. Adding a highline profile is causing more load? How should I handle this? Do you have any suggestions/recommendations?
Load Average : Very Less (its approx 10%) Regards *KrishnaKumar **N K* On Sat, 22 Aug 2020 at 08:55, KRISHNAKUMAR N K <nk.krishnaku...@gmail.com> wrote: > 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".
