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