FIFO Muxer: restart_with_keyframe does not work when drop_pkts_on_overflow false

[Wallboy]

Summary of the bug:

When using the FIFO pseudo-muxer with restart_with_keyframe enabled and drop_pkts_on_overflow disabled, when FIFO recovers, it does not drop until the next keyframe and immediately begins sending whatever frametype it left off on.

How to reproduce:

Start a local RTMP server with ffmpeg so we can mock a disconnect:

ffmpeg -f flv -listen 1 -i rtmp://127.0.0.1/app/path -f null /dev/null

Create a test source and output to local RTMP server:

ffmpeg -loglevel repeat+verbose -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 -restart_with_keyframe 1 -drop_pkts_on_overflow 0 -map 0 -flags +global_header rtmp://127.0.0.1/app/path

Then stop the RTMP server (Ctrl+C) so that the FIFO muxer goes into recovery mode. Then start the RTMP server up again.

When FIFO is able to reconnect, you expect to see "Dropping non-keyframe packet" messages, but it just ends up sending whatever frame it stopped on. You'll also see likely see h264 errors at the server side, since it can't decode these B/P frames it's now receiving.

Of course if you enable drop_pkts_on_overflow, the packets are dropped until keyframe. However, the documentation seems to imply restart_with_keyframe doesn't depend on drop_pkts_on_overflow.

It should be allowed to block the encoder while we wait for a reconnect, and then once resumed, drop until we hit a keyframe, so that RTMP servers do not receive B/P frames that can't be decoded.

This following line keeps FifoThreadContext->drop_until_keyframe from being set unless drop_pkts_on_overflow was also set:

​https://github.com/FFmpeg/FFmpeg/blob/dc7964a862890d58072ee9ca711b4b38eda5a209/libavformat/fifo.c#L374