ffmpeg hangs when recording livestreams

[h82b8]

Hey,

I wasn't sure if I should ask this question here or in the yt-dlp issues, but since it has more to do with ffmpeg I guess it makes more sense to ask here.

Every now and then ffmpeg just hangs forever when recording a livestream with yt-dlp, it just gets stuck on reading the m3u8 at random times sometimes after minutes sometimes hours.

I suppose it has to do with the server having a connection issue but the socket not closing the connection so ffmpeg just waits forever to receive something, despite the stream actually continuing.

I played around with all the timeout options in ffmpeg as well as in yt-dlp but nothing changed this behavior.

The only information that sounds like this issue online that I could find was this: http://michael-peeters.blogspot.com/2019/03/hanging-m3u8-downloads-in-ffmpeg.html?m=1

and then also this fork of ffmpeg that sounds like it deals with a similar or exactly this issue? https://github.com/bsenftner/FFmpeg

So my question I guess is, is there a way to fix this issue without a proxy and or using a different ffmpeg fork?

[nihil-admirari]

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.

[nihil-admirari]

The patch from https://github.com/FFmpeg/FFmpeg/compare/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;

[h82b8]

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.

[h82b8]

Sorry fat fingered the close comment.

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;

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

[nihil-admirari]

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).

[h82b8]

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 :)

[h82b8]

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.