[FFmpeg-user] Delay between the first packet and last packed in the muxing queue
Hi, We are seeing a black screen with complete audio and video loss with muxing error continuously when we enable debug logs. We had observed initially there were few seconds of audio loss in input and it recovered after a few seconds and from there, FFmpeg was not able to handle it and saw a blank screen. Even we tried with -vsync 0 but faced the same issue. Pls, let us know if we need to add any flag to resolve this issue or some workaround. Currently, we are restarting to resolve the issue. This is the command we are using. ffmpeg -y -v debug -analyzeduration 25M -probesize 50M -thread_queue_size 2048 -err_detect aggressive -fflags +discardcorrupt -abort_on empty_output_stream -i "udp:// 126.1.12.96:9000?fifo_size=1000_nonfatal=1" -filter_complex "[i:0xfa1]yadif[vout];[vout]split=1[out0];[out0]setdar=640/360[v0];[i:0xfa2]aresample=async=1:min_hard_comp=0.10:first_pts=0[aout];[aout]asplit=1[a0]" -f flv -vcodec libx264 -s 640x360 -r 25/1 -b:v 30 -acodec libfdk_aac -ar 48000 -b:a 64000 -sc_threshold 0 -pix_fmt yuv420p -flags +global_header+cgop -profile:v main -level 3.1 -preset fast -nal-hrd cbr -maxrate 30 -minrate 30 -bufsize 60 -g 50 -map [v0] -map [a0] rtmp://testmachine.lab2.com:1853/rtmp/push *Sample logs:* udp://126.1.12.96:9000?fifo_size=1000_nonfatal=1: corrupt decoded frame in stream 2 [h264 @ 0x52a3740] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x52a3740] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x52a3740] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0 [libx264 @ 0x4ae3a80] frame=117535 QP=30.22 NAL=2 Slice:P Poc:70 I:17 P:92 SKIP:811 size=622 bytes [NULL @ 0x4755040] ct_type:0 pic_struct:2 [h264 @ 0x588c0c0] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x588c0c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x588c0c0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0 [h264 @ 0x588c0c0] ct_type:0 pic_struct:2 [NULL @ 0x4755040] ct_type:0 pic_struct:1 udp://126.1.12.96:9000?fifo_size=1000_nonfatal=1: corrupt decoded frame in stream 2 [h264 @ 0x4d7c640] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x4d7c640] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x4d7c640] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0 [libx264 @ 0x4ae3a80] frame=117536 QP=31.80 NAL=2 Slice:P Poc:74 I:276 P:112 SKIP:532 size=1644 bytes [NULL @ 0x4755040] ct_type:0 pic_struct:2 [h264 @ 0x56e97c0] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x56e97c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x56e97c0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0 [h264 @ 0x56e97c0] ct_type:0 pic_struct:2 [NULL @ 0x4755040] ct_type:0 pic_struct:1 udp://126.1.12.96:9000?fifo_size=1000_nonfatal=1: corrupt decoded frame in stream 2 [h264 @ 0x510d240] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x510d240] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x510d240] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [libx264 @ 0x4ae3a80] frame=117537 QP=38.76 NAL=0 Slice:B Poc:72 I:9 P:63 SKIP:846 size=278 bytes [NULL @ 0x4755040] ct_type:0 pic_struct:2 [h264 @ 0x4a97c40] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x4a97c40] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x4a97c40] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x4a97c40] ct_type:0 pic_struct:2 [NULL @ 0x4755040] ct_type:0 pic_struct:1 udp://126.1.12.96:9000?fifo_size=1000_nonfatal=1: corrupt decoded frame in stream 2 [h264 @ 0x47307c0] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x47307c0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x47307c0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [libx264 @ 0x4ae3a80] frame=117538 QP=33.43 NAL=2 Slice:P Poc:76 I:299 P:45 SKIP:576 size=1860 bytes [NULL @ 0x4755040] ct_type:0 pic_struct:2 [h264 @ 0x4ae3f80] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x4ae3f80] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x4ae3f80] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x4ae3f80] ct_type:0 pic_struct:2 [NULL @ 0x4755040] ct_type:0 pic_struct:1 udp://126.1.12.96:9000?fifo_size=1000_nonfatal=1: corrupt decoded frame in stream 2 [h264 @ 0x47d8840] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x47d8840] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x47d8840] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0 [libx264 @ 0x4ae3a80] frame=117539 QP=31.99 NAL=2 Slice:P Poc:78 I:272 P:142 SKIP:506 size=1587 bytes [NULL @ 0x4755040] ct_type:0 pic_struct:2 [h264 @ 0x4ad5fc0] nal_unit_type: 9(AUD), nal_ref_idc: 0 [h264 @ 0x4ad5fc0] nal_unit_type: 6(SEI), nal_ref_idc: 0 [h264 @ 0x4ad5fc0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0 [h264 @ 0x4ad5fc0] ct_type:0 pic_struct:2 [NULL @ 0x4755040] ct_type:0 pic_struct:1 udp://126.1.12.96:9000?fifo_size=1000_nonfatal=1: corrupt decoded frame in stream 2 [h264 @ 0x4ae6080] nal_unit_type: 9(AUD),
Re: [FFmpeg-user] Delay between the first packet and last packed in the muxing queue
2014-12-08 15:44 GMT+01:00 Roger Pack rogerdpa...@gmail.com: On Sun, Dec 7, 2014 at 5:33 AM, Matej Mailing mail...@tam.si wrote: 2014-12-07 6:06 GMT+01:00 Roger Pack rogerdpa...@gmail.com: On Sat, Dec 6, 2014 at 5:58 AM, Matej Mailing mail...@tam.si wrote: Yes, that is the moment when the input drops due to some network issues, but it is back after a second or so. so what you want is an http connection that auto reconnects when the connection drops? I wonder if there's some timeout option that could be set on it [if it's timing out--it might not be...] what do you mean is back after a second or so ffmpeg doesn't seem to think it's back... Hi, this is exactly what I would like to have - an http connection that auto reconnects after the connection drop. With back after a second or so I mean that due to network issues any network input can be stopped for some time and then becomes available agan. In this case output show resume as normal. This is a very practical situation with any http input format. If you receive it with a normal input client does it get the dropped connections periodically as well? (i.e. is the connection really dropping? I assume it is?) If so then I'd file a trac item feature request reconnect http when dropped or some odd. In the meantime you could write a bash script loop to just restart ffmpeg I suppose. Cheers! -roger- Yes, the connection drops occassionally as well. I am going to open a trac feature request, but in the meantime the bash loop seems to be useful. Thank you very much for clarification! Matej Thanks, Matej Since there is no synchronization between video and sound required, I would like that ffmpeg continues playing mp3 stream. In current situation those errors keep showing up all the time and the output is never normal again - I have to manually restart ffmpef process (until the next input's drop occurs...) I think this is a very common situation with all the input streams since they can drop for some time due to many possibly network issues and resuming when the stream is available again seems to be the option we want. Thanks, Matej 2014-12-05 23:50 GMT+01:00 Roger Pack rogerdpa...@gmail.com: On Fri, Dec 5, 2014 at 12:20 AM, Matej Mailing mail...@tam.si wrote: Hi, when muxing the screen capture with the live mp3 stream, it sometimes happens that live mp3 stream becomes unavailable for a short moment (due to routing issues etc.) and when this happens, the error http://mp3.rtvslo.si/val202: Unknown error pops up. Sounds to me like the input is dropped at that point [?] ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Delay between the first packet and last packed in the muxing queue
2014-12-07 13:33 GMT+01:00 Matej Mailing mail...@tam.si: 2014-12-07 6:06 GMT+01:00 Roger Pack rogerdpa...@gmail.com: On Sat, Dec 6, 2014 at 5:58 AM, Matej Mailing mail...@tam.si wrote: Yes, that is the moment when the input drops due to some network issues, but it is back after a second or so. so what you want is an http connection that auto reconnects when the connection drops? I wonder if there's some timeout option that could be set on it [if it's timing out--it might not be...] what do you mean is back after a second or so ffmpeg doesn't seem to think it's back... Hi, this is exactly what I would like to have - an http connection that auto reconnects after the connection drop. With back after a second or so I mean that due to network issues any network input can be stopped for some time and then becomes available agan. In this case output show resume as normal. This is a very practical situation with any http input format. Thanks, Matej Since there is no synchronization between video and sound required, I would like that ffmpeg continues playing mp3 stream. In current situation those errors keep showing up all the time and the output is never normal again - I have to manually restart ffmpef process (until the next input's drop occurs...) I think this is a very common situation with all the input streams since they can drop for some time due to many possibly network issues and resuming when the stream is available again seems to be the option we want. Thanks, Matej 2014-12-05 23:50 GMT+01:00 Roger Pack rogerdpa...@gmail.com: On Fri, Dec 5, 2014 at 12:20 AM, Matej Mailing mail...@tam.si wrote: Hi, when muxing the screen capture with the live mp3 stream, it sometimes happens that live mp3 stream becomes unavailable for a short moment (due to routing issues etc.) and when this happens, the error http://mp3.rtvslo.si/val202: Unknown error pops up. Sounds to me like the input is dropped at that point [?] ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user Hi, right now from my perspective it seems that the best option is to use -shortest output option and have a cronjob checking if ffmpeg is running and if it's not, restart the process .. However this doesn't sound as a perfect solution in this case - how do you guys deal with input streams failing in such cases? Thanks! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Delay between the first packet and last packed in the muxing queue
On 12/08/2014 11:52 AM, Matej Mailing wrote: Hi, right now from my perspective it seems that the best option is to use -shortest output option and have a cronjob checking if ffmpeg is running and if it's not, restart the process .. However this doesn't sound as a perfect solution in this case - how do you guys deal with input streams failing in such cases? Thanks! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user I use an upstart script on centos6.6 with respawn option, but you may prefer any reliable supervisor daemon. Regards, Sinan ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Delay between the first packet and last packed in the muxing queue
Yes, that is the moment when the input drops due to some network issues, but it is back after a second or so. Since there is no synchronization between video and sound required, I would like that ffmpeg continues playing mp3 stream. In current situation those errors keep showing up all the time and the output is never normal again - I have to manually restart ffmpef process (until the next input's drop occurs...) I think this is a very common situation with all the input streams since they can drop for some time due to many possibly network issues and resuming when the stream is available again seems to be the option we want. Thanks, Matej 2014-12-05 23:50 GMT+01:00 Roger Pack rogerdpa...@gmail.com: On Fri, Dec 5, 2014 at 12:20 AM, Matej Mailing mail...@tam.si wrote: Hi, when muxing the screen capture with the live mp3 stream, it sometimes happens that live mp3 stream becomes unavailable for a short moment (due to routing issues etc.) and when this happens, the error http://mp3.rtvslo.si/val202: Unknown error pops up. Sounds to me like the input is dropped at that point [?] ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Re: [FFmpeg-user] Delay between the first packet and last packed in the muxing queue
On Sat, Dec 6, 2014 at 5:58 AM, Matej Mailing mail...@tam.si wrote: Yes, that is the moment when the input drops due to some network issues, but it is back after a second or so. so what you want is an http connection that auto reconnects when the connection drops? I wonder if there's some timeout option that could be set on it [if it's timing out--it might not be...] what do you mean is back after a second or so ffmpeg doesn't seem to think it's back... Since there is no synchronization between video and sound required, I would like that ffmpeg continues playing mp3 stream. In current situation those errors keep showing up all the time and the output is never normal again - I have to manually restart ffmpef process (until the next input's drop occurs...) I think this is a very common situation with all the input streams since they can drop for some time due to many possibly network issues and resuming when the stream is available again seems to be the option we want. Thanks, Matej 2014-12-05 23:50 GMT+01:00 Roger Pack rogerdpa...@gmail.com: On Fri, Dec 5, 2014 at 12:20 AM, Matej Mailing mail...@tam.si wrote: Hi, when muxing the screen capture with the live mp3 stream, it sometimes happens that live mp3 stream becomes unavailable for a short moment (due to routing issues etc.) and when this happens, the error http://mp3.rtvslo.si/val202: Unknown error pops up. Sounds to me like the input is dropped at that point [?] ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
[FFmpeg-user] Delay between the first packet and last packed in the muxing queue
Hi, when muxing the screen capture with the live mp3 stream, it sometimes happens that live mp3 stream becomes unavailable for a short moment (due to routing issues etc.) and when this happens, the error http://mp3.rtvslo.si/val202: Unknown error pops up. After this error is shown it takes about 10 seconds to start popping up messages: [mpegts @ 02b93500] Delay between the first packet and last packet in the muxing queue is 1010 1000: forcing output Last message repeated 4 times frame=102640 fps= 10 q=2.0 size= 1307240kB time=02:51:03.80 bitrate=1043.4kbits/ [mpegts @ 02b93500] Delay between the first packet and last packet in the muxing queue is 1010 1000: forcing output Last message repeated 4 times frame=102645 fps= 10 q=2.0 size= 1307371kB time=02:51:04.30 bitrate=1043.4kbits/ [mpegts @ 02b93500] Delay between the first packet and last packet in the muxing queue is 1010 1000: forcing output Last message repeated 4 times This is the command we are using: ffmpeg -loglevel debug -rtbufsize 2000M -threads 4 -vsync 0 -f dshow -i video=UScreenCapture -re -ss 1 -rtbufsize 900M -vsync 0 -i http://mp3.rtvslo.si/val202; -acodec copy -vcodec mpeg2video -s 720x576 -qscale:v 2 -r 10 -f mpegts -b:v 700k -minrate:v 700k -map 0:0 -map 1:0 z:\testinfo\file.ts The sound is gone then while the video remains and those errors continue endlessly. I would like that mp3 stream resumes after some network issues disable its' availability for a short time - there is no synchronization between video and audio required (they are two independent sources). Thanks, Matej ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
