ffmpeg hangs when recording livestreams about ffmpeg-builds HOT 7 CLOSED

From the comments to http://michael-peeters.blogspot.com/2019/03/hanging-m3u8-downloads-in-ffmpeg.html?m=1:

Apparently ffmpeg has a flag named "rw_timeout" that should enforce a read timeout on the TCP socket. By default it has a value of -1, meaning that in the worst case it would hang forever. I'll give that a try before I go tinyproxy.
Edit: Since it looks you're also using youtube-dl, you would be able to specify this flag like so: youtube-dl --external-downloader-args '-rw_timeout 10000000' ...

Have you tried that? If it works, then making yt-dlp pass -rw_timeout would be easier than patching FFmpeg.

from ffmpeg-builds.

The patch from FFmpeg/FFmpeg@master...bsenftner:FFmpeg:master doesn't seem to be usable: it simply makes av_read_frame call a given callback, but no default callback is provided. Apparently the patch was done to support that guy's ffvideo, since the example uses the callback from ffvideo:

AVFormatContext* p_format_context = avformat_alloc_context();
p_format_context->interrupt_callback.callback = FFVideo_FrameMgr::interrupt_callback;
p_format_context->interrupt_callback.opaque = mp_frameMgr;

from ffmpeg-builds.

From the comments to http://michael-peeters.blogspot.com/2019/03/hanging-m3u8-downloads-in-ffmpeg.html?m=1:

Apparently ffmpeg has a flag named "rw_timeout" that should enforce a read timeout on the TCP socket. By default it has a value of -1, meaning that in the worst case it would hang forever. I'll give that a try before I go tinyproxy.
Edit: Since it looks you're also using youtube-dl, you would be able to specify this flag like so: youtube-dl --external-downloader-args '-rw_timeout 10000000' ...

Have you tried that? If it works, then making yt-dlp pass -rw_timeout would be easier than patching FFmpeg.

Yeah, I tried that before and it didn't change the behavior I described.

from ffmpeg-builds.

Sorry fat fingered the close comment.

The patch from FFmpeg/[email protected]:FFmpeg:master doesn't seem to be usable: it simply makes av_read_frame call a given callback, but no default callback is provided. Apparently the patch was done to support that guy's ffvideo, since the example uses the callback from ffvideo:

AVFormatContext* p_format_context = avformat_alloc_context();
p_format_context->interrupt_callback.callback = FFVideo_FrameMgr::interrupt_callback;
p_format_context->interrupt_callback.opaque = mp_frameMgr;

I see, well I guess then the only thing I can try would be the proxy unless you have another idea?

from ffmpeg-builds.

RSTP does not respect -rw_timeout: https://fftrac-bg.ffmpeg.org/ticket/7609.

Try -timeout and -stimeout. There are also -reconnect options.

If none work: you can try asking in the main repo to forcefully kill FFmpeg on timeout if it haven't written anything to stdout/stderr (not sure how it would interactive with resume download though).

from ffmpeg-builds.

RSTP does not respect -rw_timeout: https://fftrac-bg.ffmpeg.org/ticket/7609.

Try -timeout and -stimeout. There are also -reconnect options.

If none work: you can try asking in the main repo to forcefully kill FFmpeg on timeout if it haven't written anything to stdout/stderr (not sure how it would interactive with resume download though).

I tried the -timeout/-stimeout commands before but i give -reconnect a shot, I'll report back if this helps or I'll find something else.

thanks for the help so far :)

from ffmpeg-builds.

I tried out all the commands, none of them worked.

Randomly it still just hangs and then sits forever waiting, until I end it by 2x ctrl+c

I googled around some more and found a couple of people that describe the same issue but none with a solution.

So I guess I'll now wait until someone responds from the mailing list @ ffmpeg, if someone has any other idea what I can try in the meantime, I'll be happy to hear it.

from ffmpeg-builds.