[FFmpeg-trac] #6775(avcodec:new): gst-libav can no longer decode video (3.4 regression)

[FFmpeg]

#6775: gst-libav can no longer decode video (3.4 regression)
------------------------------------+-----------------------------------
             Reporter:  heftig      |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  critical    |                Component:  avcodec
              Version:              |               Resolution:
             Keywords:  regression  |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+-----------------------------------

Comment (by jcowgill):

 I think Kodi 17 is also affected by this (for people who don't use Kodi's
 bundled ffmpeg).
 See: https://bugs.gentoo.org/634802

 I have this hack which forces the buffers to be flushed after a drain has
 completed. It allows gst-libav and kodi to work with ffmpeg 3.4, but I
 expect it has some side effect I haven't thought of :) It should have the
 same effect as doing (3) above.

 {{{
 --- a/libavcodec/decode.c
 +++ b/libavcodec/decode.c
 @@ -780,6 +780,10 @@ static int compat_decode(AVCodecContext *avctx,
 AVFrame *frame,
      while (ret >= 0) {
          ret = avcodec_receive_frame(avctx, frame);
          if (ret < 0) {
 +            if (ret == AVERROR_EOF) {
 +                av_assert0(avci->draining);
 +                avcodec_flush_buffers(avctx);
 +            }
              if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
                  ret = 0;
              goto finish;
 }}}

 I think there is a misunderstanding here about what a NULL packet sent via
 avcodec_video_decode2 actually does, probably because the documentation is
 a bit lacking in this area. The documentation says you need a NULL packet
 at the end of a stream, but says nothing about NULL packets sent at any
 other time. There are at least a few comments I found in the ffmpeg source
 which imply that sending a NULL packet means EOF (as opposed to draining,
 and allowing extra data later). Clearly the developer who wrote the compat
 code in 3.4 thought this as well.

 Maybe I'm missing something obvious, but why does gst-libav need to drain
 the codec when a packet is dropped?

--
Ticket URL: <https://trac.ffmpeg.org/ticket/6775#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker