[FFmpeg-user] Latency in UDP to HLS Conversion

Mon Aug 24 07:26:58 EEST 2020

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.krishnakumar at 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://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".
>
>