Latency in UDP to HLS Conversion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Latency in UDP to HLS Conversion

KRISHNAKUMAR N K
Hi Guys

I am converting UDP Input to Live HLS output and pushing the chunks to a
webdav server. Initial playback works fine, but the playback was delayed by
almost an hour, when we checked after 15 hours. I can also see that the cpu
load average is very less.

*ffmpeg :*










*ffmpeg version 4.3 Copyright (c) 2000-2020 the FFmpeg developers  built
with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-36)  configuration:
--prefix=/root/ffmpeg-4.3/ffmpeg_build --pkg-config-flags=--static
--extra-cflags='-I/root/ffmpeg-4.3/ffmpeg_build/include
-I/usr/local/cuda/include'
--extra-ldflags='-L/root/ffmpeg-4.3/ffmpeg_build/lib
-L/usr/local/cuda/lib64' --extra-libs=-lpthread --extra-libs=-lm
--bindir=/root/ffmpeg-4.3/bin --enable-gpl --enable-libfdk_aac
--enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvpx
--enable-libx264 --enable-libx265 --enable-cuda --enable-cuvid
--enable-nvenc --enable-libnpp --enable-nonfree --enable-openssl  libavutil
     56. 51.100 / 56. 51.100  libavcodec     58. 91.100 / 58. 91.100
libavformat    58. 45.100 / 58. 45.100  libavdevice    58. 10.100 / 58.
10.100  libavfilter     7. 85.100 /  7. 85.100  libswscale      5.  7.100 /
 5.  7.100  libswresample   3.  7.100 /  3.  7.100  libpostproc    55.
 7.100 / 55.  7.100*

Below is the ffmpeg command that i am using. Any help would be appreciated.






*ffmpeg -i "udp://230.1.1.15:10000?fifo_size=10000000&overrun_nonfatal=1
<http://230.1.1.15:10000?fifo_size=10000000&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 libx264 -s:v:0 256x144 -tune film -r:v:0 25 -b:v:0 100000
-maxrate:v:0 100000 -minrate:v:0 100000 -bufsize:v:0 200000 -acodec
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 fast
-nal-hrd cbr -keyint_min 50 -g 50 -map [v0] -map [a0] \-vcodec libx264
-s:v:1 512x288 -tune film -r:v:1 25 -b:v:1 200000 -maxrate:v:1 200000
-minrate:v:1 200000 -bufsize:v:1 400000 -acodec libfdk_aac -ar:1 48000
-b:a:1 48000 -sc_threshold 0 -pix_fmt yuv420p -flags +global_header+cgop
-profile:v:1 baseline -level:v:1 3.0 -preset fast -nal-hrd cbr -keyint_min
50 -g 50 -map [v1] -map [a1] \-vcodec libx264 -s:v:2 640x360 -tune film
-r:v:2 25 -b:v:2 700000 -maxrate:v:2 700000 -minrate:v:2 700000
-bufsize:v:2 1400000 -acodec libfdk_aac -ar:2 48000 -b:a:2 48000
-sc_threshold 0 -pix_fmt yuv420p -flags +global_header+cgop -profile:v:2
main -level:v:2 3.1 -preset fast -nal-hrd cbr -keyint_min 50 -g 50 -map
[v2] -map [a2] \-vcodec libx264 -s:v:3 1280x720 -tune film -r:v:3 25 -b:v:3
1000000 -maxrate:v:3 1000000 -minrate:v:3 1000000 -bufsize:v:3 2000000
-acodec libfdk_aac -ar:3 48000 -b:a:3 48000 -sc_threshold 0 -pix_fmt
yuv420p -flags +global_header+cgop -profile:v:3 high -level:v:3 4.0 -preset
fast -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
<a href="https://usr:pass@example.com:8043/httppush/media_%v_%03d.ts">https://usr:pass@...:8043/httppush/media_%v_%03d.ts -hls_flags
delete_segments+independent_segments+discont_start
<a href="https://usr:pass@example.com:8043/httppush/playlist_%v.m3u8*">https://usr:pass@...:8043/httppush/playlist_%v.m3u8*

Regards

*KrishnaKumar **N K *
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Latency in UDP to HLS Conversion

Moritz Barsnick
On Wed, Aug 19, 2020 at 18:57:09 +0530, KRISHNAKUMAR N K wrote:
> Hi Guys
>
> I am converting UDP Input to Live HLS output and pushing the chunks to a
> webdav server. Initial playback works fine, but the playback was delayed by
> almost an hour, when we checked after 15 hours. I can also see that the cpu
> load average is very less.
[...]
> Below is the ffmpeg command that i am using. Any help would be appreciated.

We would appreciate its complete, uncut console output. If it's over,
let's say, 2500 lines, and repetetive in the middle, please post the
first 50 and last 50 lines, and upload the complete output somewhere
else.

> *ffmpeg -i "udp://230.1.1.15:10000?fifo_size=10000000&overrun_nonfatal=1
> <http://230.1.1.15:10000?fifo_size=10000000&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 libx264 -s:v:0 256x144 -tune film -r:v:0 25 -b:v:0 100000
[...]

Does the latency also happen with only one output? Or without yadif
filter?

Thanks,
Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Latency in UDP to HLS Conversion

KRISHNAKUMAR N K
Hi Moritz

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

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.

Regards

*KrishnaKumar **N K*

On Thu, 20 Aug 2020 at 17:39, Moritz Barsnick <[hidden email]> wrote:

> On Wed, Aug 19, 2020 at 18:57:09 +0530, KRISHNAKUMAR N K wrote:
> > Hi Guys
> >
> > I am converting UDP Input to Live HLS output and pushing the chunks to a
> > webdav server. Initial playback works fine, but the playback was delayed
> by
> > almost an hour, when we checked after 15 hours. I can also see that the
> cpu
> > load average is very less.
> [...]
> > Below is the ffmpeg command that i am using. Any help would be
> appreciated.
>
> We would appreciate its complete, uncut console output. If it's over,
> let's say, 2500 lines, and repetetive in the middle, please post the
> first 50 and last 50 lines, and upload the complete output somewhere
> else.
>
> > *ffmpeg -i "udp://230.1.1.15:10000?fifo_size=10000000&overrun_nonfatal=1
> > <http://230.1.1.15:10000?fifo_size=10000000&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 libx264 -s:v:0 256x144 -tune film -r:v:0 25 -b:v:0 100000
> [...]
>
> Does the latency also happen with only one output? Or without yadif
> filter?
>
> Thanks,
> Moritz
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Latency in UDP to HLS Conversion

Moritz Barsnick
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Latency in UDP to HLS Conversion

KRISHNAKUMAR N K
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
<a href="https://www@mail.com:test123@domain.com:8043/httppush/1/media_%v_%03d.ts">https://www@...:test123@...:8043/httppush/1/media_%v_%03d.ts
-hls_flags delete_segments+independent_segments+discont_start
<a href="https://www@mail.com:test123@domain.com:8043/httppush/1/playlist_%v.m3u8*">https://www@...:test123@...: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 <[hidden email]> 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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Latency in UDP to HLS Conversion

KRISHNAKUMAR N K
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 <[hidden email]>
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
> <a href="https://www@mail.com:test123@domain.com:8043/httppush/1/media_%v_%03d.ts">https://www@...:test123@...:8043/httppush/1/media_%v_%03d.ts
> -hls_flags delete_segments+independent_segments+discont_start
> <a href="https://www@mail.com:test123@domain.com:8043/httppush/1/playlist_%v.m3u8*">https://www@...:test123@...: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 <[hidden email]> 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
>> [hidden email]
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> [hidden email] with subject "unsubscribe".
>
>
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Latency in UDP to HLS Conversion

KRISHNAKUMAR N K
In reply to this post by Moritz Barsnick
On Fri, 21 Aug 2020 at 11:57, Moritz Barsnick <[hidden email]> 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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Latency in UDP to HLS Conversion

andrei ka
hi,

a side note, afaik, hls spec advises: "...for broadest compatibility,
Variant Streams SHOULD contain the same encoded audio bitstream..." ;

&rei



On Mon, Aug 24, 2020 at 8:03 AM KRISHNAKUMAR N K <[hidden email]>
wrote:

> On Fri, 21 Aug 2020 at 11:57, Moritz Barsnick <[hidden email]> 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
> > [hidden email]
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >
> > To unsubscribe, visit link above, or email
> > [hidden email] with subject "unsubscribe".
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".