Opened 18 months ago
#11467 new defect
FIFO Muxer: restart_with_keyframe recovers on audio packets
| Reported by: | Wallboy | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avformat |
| Version: | 7.1 | Keywords: | fifo muxer |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Summary of the bug:
When using restart_with_keyframe in the FIFO muxer, I believe the expectation is that packets are dropped until the next video keyframe. The current behavior is that it will recover if it also encounters any audio packet, as they are flagged as a keyframe.
If this is the expected behavior, then perhaps an additional option should be added to FIFO to allow resumption only on video keyframes as well. This is particularly useful if you are reconnecting to an RTMP server and wish to make sure you're sending a keyframe first and not a B/P frame.
How to reproduce:
Start a local ffmpeg RTMP server:
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" -f lavfi -i "sine=frequency=1000:duration=600" -c:v libx264 -pix_fmt yuv420p -f fifo -fifo_format flv -attempt_recovery 1 -restart_with_keyframe 1 -drop_pkts_on_overflow 1 -map 0:v -map 1:a -flags +global_header rtmp://127.0.0.1/app/path
NOTE: drop_pkts_on_overflow must be set to 1 here, otherwise frames will not be dropped until keyframe. (See my other newly created ticket for this issue: https://trac.ffmpeg.org/ticket/11466)
Attach to the second ffmpeg using your debugger of choice and set a breakpoint on this line: https://github.com/FFmpeg/FFmpeg/blob/dc7964a862890d58072ee9ca711b4b38eda5a209/libavformat/fifo.c#L193
Stop the ffmpeg server (Ctrl+C), so that the FIFO muxer goes into recovery mode. Then start the server back up and wait for FIFO to reconnect and hit the breakpoint. Notice any audio packets received at this point will be considered a keyframe, and hence will resume sending audio/video packets from that point on.


