#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
