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