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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
