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
