[FFmpeg-trac] #11469(ffmpeg:new): ffmpeg_demux: readrate plays "catch up" if output is blocked, then later resumed

[FFmpeg]

#11469: ffmpeg_demux: readrate plays "catch up" if output is blocked, then later
resumed
-------------------------------------+-------------------------------------
             Reporter:  Wallboy      |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:  ffmpeg       |                  Version:  7.1
             Keywords:  demuxer      |               Blocked By:
  readrate                           |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 **Summary of the bug:**

 Certain muxers such as FIFO can block the input if the output is not
 currently writable. Such is the case if the FIFO muxer has
 drop_pkts_on_overflow 0 and attempt_recovery 1, and you are outputting to
 something like RTMP, and the RTMP server goes down temporarily.

 Assuming the "-re" option was used. aka readrate = 1.

 Once the RTMP server reconnects after sometime, the FIFO muxer recovers
 and can now continue. Now when ffmpeg starts reading from the input and
 calls **readrate_sleep(Demuxer *d)**, it essentially sees we've fallen
 behind and needs to play "catch up", and does not sleep and sends packets
 as quick as possible until it makes up the time it lost.

 This means the output you are expecting to be sending at native input rate
 of 1x instead gets blasted with a surge of packets, which is worse
 depending on the amount of time the passed before a reconnect was
 successful. An RTMP server that has a rate limit on ingest would most
 certainly just disconnect you at this point.


 **How to reproduce:**

 We can show this through using ffmpeg running it's own RTMP server:

 {{{
 ffmpeg -f flv -listen 1 -i rtmp://127.0.0.1/app/path -vf showinfo -f null
 /dev/null
 }}}

 Create a testsrc to send to this server:

 {{{
 ffmpeg -re -f lavfi -i "testsrc=duration=600:size=640x360:rate=30" -c:v
 libx264 -pix_fmt yuv420p -f fifo -fifo_format flv -attempt_recovery 1
 -drop_pkts_on_overflow 0 -map 0 -flags +global_header
 rtmp://127.0.0.1/app/path
 }}}

 In the server output, take note of the speed of frames from the showinfo
 filter (the n: value). Now disconnect the ffmpeg RTMP server (Ctrl+C) and
 wait for some time to pass (30 seconds to a minute). Then start the server
 back up and wait for the FIFO command to recovery and reconnect.

 Now take note of how fast the incoming frames are compared to before. This
 quickly continues to climb up before it slows back down once the
 readrate_sleep() function determines it has caught up.

 Seems this function would need to be aware of when the output has stalled.
 Not sure how simple of a fix this would be.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11469>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker