rtmp_write dead loop

[Palich]

ffmpeg hangs tightly in the function retry_transfer_wrapper when the rtmp stream is published. This can happen in 5 minutes or an hour after the start of the broadcast. The function RTMP_Write () returns 0, this is not an error, but it indicates that it could not transfer data, this causes the write cycle to hang.

ffmpeg -nostats -xerror -err_detect compliant -loglevel info -vsync passthrough -frame_drop_threshold 4 -headers Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20150101 Firefox/47.0 (Chrome)? Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8? Accept-Language: en-us,en;q=0.5? Youtubedl-no-compression: True? Accept-Encoding: gzip, deflate?  -fflags +genpts -i https://manifest.googlevideo.com/api/manifest/hls_playlist/id/r1L1J7E4oog.0/itag/95/source/yt_live_broadcast/requiressl/yes/ratebypass/yes/live/1/cmbypass/yes/goi/160/sgoap/gir%3Dyes%3Bitag%3D140/sgovp/gir%3Dyes%3Bitag%3D136/hls_chunk_host/r4---sn-bpb5oxu-3c26.googlevideo.com/ei/tQWZWqz7PNqFyAXCgLLoDA/playlist_type/DVR/gcr/ua/initcwndbps/133470/mm/32/mn/sn-bpb5oxu-3c26/ms/lv/mv/m/pl/24/dover/10/keepalive/yes/mt/1519977742/ip/195.137.167.181/ipbits/0/expire/1519999510/sparams/ip,ipbits,expire,id,itag,source,requiressl,ratebypass,live,cmbypass,goi,sgoap,sgovp,hls_chunk_host,ei,playlist_type,gcr,initcwndbps,mm,mn,ms,mv,pl/signature/828CDB2191F0FD1BCEB3D09693C9FD38A5019093.843CBBCAA1E3C32882E36DDD448A15AB1F595D53/key/dg_yt0/playlist/index.m3u8 -init_hw_device qsv:hw -filter_complex yadif=0:1:0,eq=1.1:0:1.25,scale=640:360:1 -g 50 -aspect 16:9 -c:v h264_qsv -profile:v main -pix_fmt nv12 -tune zerolatency -level 4.1 -aspect 16:9 -preset medium -b:v 800k -minrate:v 800k -maxrate:v 800k -bufsize:v 2400k -g 25 -strict experimental -strict experimental -acodec aac -ab 64k -ar 44100 -af aresample=async=1:min_hard_comp=0.200000:first_pts=0 -f flv rtmp://localhost/vip/_1_

ffmpeg version N-90182-g40102a2
built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-11)

Thread 1 (Thread 0x7fa95f2a6840 (LWP 18390)):
#0  0x000000000041f523 in decode_interrupt_cb (ctx=0x0) at fftools/ffmpeg.c:471
#1  0x00007fa95e420ca7 in retry_transfer_wrapper (transfer_func=0x7fa95e477e30 <rtmp_write>, size_min=32768, size=32768, buf=0x2a87640 "\t", h=0x2904900) at libavformat/avio.c:374
#2  ffurl_write (h=0x2904900, buf=0x2a87640 "\t", size=32768) at libavformat/avio.c:429
#3  0x00007fa95e423b61 in writeout (len=32768, data=<optimized out>, s=0x2a8f780) at libavformat/aviobuf.c:163
#4  flush_buffer (s=0x2a8f780) at libavformat/aviobuf.c:184
#5  avio_write (s=s@entry=0x2a8f780, buf=0x3ee5550 "", size=32752) at libavformat/aviobuf.c:231
#6  0x00007fa95e446f10 in flv_write_packet (s=0x29dde80, pkt=0x7ffe3a82fd80) at libavformat/flvenc.c:1031
#7  0x00007fa95e4cf8f5 in write_packet (pkt=0x7ffe3a82fd80, s=0x29dde80) at libavformat/mux.c:747
#8  av_interleaved_write_frame (s=s@entry=0x29dde80, pkt=0x0, pkt@entry=0x7ffe3a830250) at libavformat/mux.c:1231
#9  0x0000000000421c82 in write_packet (pkt=pkt@entry=0x7ffe3a830250, ost=ost@entry=0x2901500, unqueue=unqueue@entry=0, of=0x1e5f940, of=0x1e5f940) at fftools/ffmpeg.c:807
#10 0x0000000000424515 in output_packet (of=of@entry=0x1e5f940, pkt=pkt@entry=0x7ffe3a830250, ost=ost@entry=0x2901500, eof=0) at fftools/ffmpeg.c:878
#11 0x0000000000425450 in do_video_out (of=of@entry=0x1e5f940, ost=ost@entry=0x2901500, next_picture=next_picture@entry=0x39e7bc0, sync_ipts=<optimized out>, sync_ipts@entry=72723.160011291504) at fftools/ffmpeg.c:1312
#12 0x0000000000429226 in reap_filters (flush=flush@entry=0) at fftools/ffmpeg.c:1498
#13 0x0000000000408fe9 in transcode_step () at fftools/ffmpeg.c:4592
#14 transcode () at fftools/ffmpeg.c:4636
#15 main (argc=<optimized out>, argv=<optimized out>) at fftools/ffmpeg.c:4839

[Carl Eugen Hoyos]

Is network input required to reproduce this issue?

[Palich]

Yes, and thus it should be YouTube.
The problem occurs when the network source (hls) and the network receiver (rtmp)

[Alexsey Shestakov]

Have same defect, digging in code gives clear suspect

​https://github.com/FFmpeg/FFmpeg/commit/858db4b01fa2b55ee55056c033054ca54ac9b0fd#diff-402ee51614912c70237d99b3fe73cb27

With this commit, retry_transfer_wrapper don't consider 0 as EOS signal, commit change this behaviour in some parts of code but not in librtmp.

So retry_transfer_wrapper do endless retry and there we have dead loop

Reverting first diff from commit fixed issue for me, but brokes something else. Clear fix requires librtmp wrapper that change 0 to EOS. Other option - change librtmp

[Timo R.]

I can confirm this issue, it happens oh both 4.0.x and master, 3.4 works fine.

I also want to note that I have the exact same issue, no matter if I build ffmpeg with or without librtmp enabled.

[Timo R.]

Quick attempt at a patch for this, so far entirely untested:
​https://github.com/BtbN/FFmpeg/commit/e4b8bfaa3d5d2eae866201bbb6c6649e6875a6b7.patch

[Timo R.]

That patch has seemed to fix the issue with librtmp enabled, at least I was able to run a prolonged test stream without any hangs. I pushed it to master and release/4.0, since it in any case fixes an issue.

I'd like someone else to confirm this before closing this issue.

[Carl Eugen Hoyos]

Fixed by Timo in ed647ab79f9a54d8d3a8e345f6a1643b60b849f4