Opened 4 years ago

Closed 3 years ago

#7052 closed defect (fixed)

rtmp_write dead loop

Reported by: Palich Owned by:
Priority: important Component: avformat
Version: git-master Keywords: rtmp deadlock
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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,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

Change History (8)

comment:1 by Carl Eugen Hoyos, 4 years ago

Keywords: rtmp deadlock added; rtmp_write dead loop removed
Priority: criticalimportant

Is network input required to reproduce this issue?

comment:2 by Palich, 4 years ago

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

comment:3 by Alexsey Shestakov, 3 years ago

Have same defect, digging in code gives clear suspect

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

comment:4 by Timo R., 3 years ago

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.

Last edited 3 years ago by Timo R. (previous) (diff)

comment:5 by Timo R., 3 years ago

Quick attempt at a patch for this, so far entirely untested:

comment:6 by Timo R., 3 years ago

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.

comment:7 by Tristan Matthews, 3 years ago

Cc: added

comment:8 by Carl Eugen Hoyos, 3 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.