gst-libav can no longer decode video (3.4 regression)
|Reported by:||Jan Alexander Steffens||Owned by:|
|Cc:||email@example.com, firstname.lastname@example.org, email@example.com, Michael Niedermayer||Blocked By:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
Summary of the bug:
gst-libav attempts to drain the decoder (by feeding avcodec_decode_video2 empty packets) before every discontinuity in the stream. The compat implementation used since 3.4 doesn't seem to handle this case correctly. It does not consume any data from the following (real) packets and further calls echo a message: "Got unexpected packet size after a partial decode"
Since the start of the stream is also considered a discontinuity, the decode can't even start. Avoiding draining at the start of the stream doesn't solve the problem for any further discontinuity.
Downstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=789193
How to reproduce:
gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay ! identity drop-probability=0.1 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! autovideosink
This creates a h264 stream which is missing 10% of frames.
(1) With FFmpeg 3.3, it manages a best-effort (glitchy) decode.
(2) With FFmpeg 3.4, it does not start decoding at all.
(3) Reverting gst-libav commit 67e55e47 (or inserting a call to avcodec_flush_buffers after draining) allows decoding to start, but causes the decoder state to be cleared after each missing frame, creating much worse output than (1).