GNOME Bugzilla – Bug 796334
avdec_h264 looses reference frames after lost packages
Last modified: 2018-08-29 07:23:02 UTC
Since the update to ffmpeg n3.4.1 (1.12.0-39-g829b269e1ef3) avdec_h264 handles packet loss badly. This pipeline shows this nicely: gst-launch-1.0 videotestsrc pattern=ball ! x264enc key-int-max=60 ! \ rtph264pay ! identity drop-probability=0.01 ! queue ! rtph264depay ! \ avdec_h264 ! autovideosink With gst-libav before the mentioned commit, it looks like the last decoded frame is uses as a reference frame. This results in minor artifacts but the video is still recognizable. After this commit an empty frame is a reference frame. As a result the video is a grey mess until the next I-Frame. I tracked this down to two relevant commits in ffmpeg: 061a0c14bb57 decode: restructure the core decoding code d8d1689f929c avcodec/decode: reset codec on receiving packet after EOF in compat_decode With the first one and without the second one playback is completely broken. If I back-port the second commit onto the first one, then I get the error described above. All commits before the first one are good. The commit message of the second commit looks suspicious: [...] To restore some compatibility, reset the codec if we receive a new non-drain packet using the old API after draining has completed. While this does not give the same behaviour as the old API did, in the majority of cases it works and it does not require changes to any other part of the decoding code. [...] Maybe we need to switch to the new API?
(In reply to Michael Olbrich from comment #0) > Maybe we need to switch to the new API? Which new API? avcodec_send_packet(), avcodec_receive_frame(), etc? Those are used in GIT master now, together with ffmpeg 4.0
The old API was used when I opened this bug. I expect that this problem is solved with the latest changes in git master (from Bug 792900). I cannot test this right now, but if there are still problems, then it's a different issue.