[FFmpeg-user] Delay between the first packet and last packed in the muxing queue

Roger Pack rogerdpack2 at gmail.com
Mon Dec 8 15:44:48 CET 2014


On Sun, Dec 7, 2014 at 5:33 AM, Matej Mailing <mailing at tam.si> wrote:

> 2014-12-07 6:06 GMT+01:00 Roger Pack <rogerdpack2 at gmail.com>:
> > On Sat, Dec 6, 2014 at 5:58 AM, Matej Mailing <mailing at 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-





> 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 <rogerdpack2 at gmail.com>:
> >> > On Fri, Dec 5, 2014 at 12:20 AM, Matej Mailing <mailing at 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 at ffmpeg.org
> >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >> _______________________________________________
> >> ffmpeg-user mailing list
> >> ffmpeg-user at ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >>
> > _______________________________________________
> > ffmpeg-user mailing list
> > ffmpeg-user at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>


More information about the ffmpeg-user mailing list