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

Matej Mailing mailing at tam.si
Wed Dec 10 20:58:53 CET 2014


2014-12-08 15:44 GMT+01:00 Roger Pack <rogerdpack2 at gmail.com>:
> 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-
>
>

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 <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
>>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user


More information about the ffmpeg-user mailing list