#11469: ffmpeg_demux: readrate plays "catch up" if output is blocked, then later
resumed
-------------------------------------+-------------------------------------
Reporter: Wallboy | Owner: (none)
Type: defect | Status: new
Priority: normal | Component: ffmpeg
Version: 7.1 | Resolution:
Keywords: demuxer | Blocked By:
readrate |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Description changed by Wallboy:
Old description:
> **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.
New description:
**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.
**EDIT:** The **realtime** filter could potentially be a solution, but
this wouldn't work for if you wanted to use streamcopy.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11469#comment:1>
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".
