On 30/10/2017 16:50, James Cowgill wrote:
Hi,
This is an issue which was reported in a number of places. I'm asking
here since libav was the origin of the commit which broke things and
hopefully someone here has an answer.
https://trac.ffmpeg.org/ticket/6775
https://bugzilla.gnome.org/show_bug.cgi?id=789193
https://bugs.debian.org/879673
In commit 061a0c14bb57 ("decode: restructure the core decoding code"),
the avcodec_decode_* APIs were rewritten in terms of the new
avcodec_send_packet / avcodec_receive_frame APIs. Unfortunately this
changed the behavior of the old APIs on receipt of a NULL packet. In the
old API this meant "drain the codec of the remaining frames". Usually
this was done at the end of the stream, but it worked (to an extent)
when done in the middle of a stream. In the new API, a NULL packet means
the end of file and no more packets can be sent to the codec. Since NULL
packets are passed through to avcodec_send_packet in the compatability
code added in the above commit, applications which send NULL packets in
the middle of a stream are broken with new libav / ffmpeg.
gst-libav exploited this by sending NULL packets to
avcodec_decode_video4 whenever some input packets were lost
(unfortunately I don't know the details of this very well). It also
sends a NULL packet before trying to decode anything.
My questions are: is what gst-libav is doing legal in the old API? If it
is, what can be done to fix it? If it isn't, what is gst-libav supposed
to do to avoid loosing functionality?
Thanks,
James
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
avcodec_flush_buffers should do at least 1/2 of what you want to do.
lu
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
