RTMP cannot receive live stream more than 4GB

[tyama]

Summary of the bug:

RTMP cannot receive live stream more than 4GB.
When ffmpeg recieved 4GB, it stop and print message "No more output streams to write to, finishing.".

I attach the log of '-report' option. (ffmpeg-20160909-041937.zip)

How to reproduce:

 ffmpeg -v 9 -loglevel 99 -report -i rtmp://<Adobe Media Server FQDN>/livepkgr/mp4:fmletest2 -vcodec copy -acodec copy /home/tyama/test_ffmpeg/test_fmle.mp4 > ffmpeg_rtmp.log 2>&1

• ffmpeg infomation

$ ffmpeg -version
ffmpeg version N-81609-g7b3bc36 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-17)
configuration:
libavutil      55. 29.100 / 55. 29.100
libavcodec     57. 55.101 / 57. 55.101
libavformat    57. 48.103 / 57. 48.103
libavdevice    57.  0.102 / 57.  0.102
libavfilter     6. 61.100 /  6. 61.100
libswscale      4.  1.100 /  4.  1.100
libswresample   2.  1.100 /  2.  1.100

• System environment infomation -- CentOS release 6.6, x64, ext4 file system

• Live stream is published by Flash Media Live Encoder. (However, this problem also occur in other live source.) -- Video Format H264 -- Audio Format Mp3

• Adobe Media Server infomation -- Adobe Media Server 5.0.9 -- CentOS release 6.7 x64

[iluvatar]

I had the same issue.
In my case following code fix it:

diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index 72d6341..58f5994 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2432,6 +2432,10 @@ static int get_packet(URLContext *s, int for_header)
         rt->last_timestamp = rpkt.timestamp;

         rt->bytes_read += ret;
+        if (rt->bytes_read > 0xF0000000) {
+            rt->bytes_read -= 0xF0000000;
+            rt->last_bytes_read -= 0xF0000000;
+        }
         if (rt->bytes_read - rt->last_bytes_read > rt->client_report_size) {
             av_log(s, AV_LOG_DEBUG, "Sending bytes read report\n");
             if ((ret = gen_bytes_read(s, rt, rpkt.timestamp + 1)) < 0)

[Carl Eugen Hoyos]

Could you also test the attached patch?

[Carl Eugen Hoyos]

Hopefully fixed in 75bd4ea02400ffa5fa95569a9cf3213c64e651fb