On Mon, 30 Oct 2017 15:50:58 +0000 James Cowgill <[email protected]> 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? What you're describing sounds like they rely on automatic EOF recovery: if you send NULL packets (i.e. EOF), and after that normal packets again, then most decoders will resume decoding normally. This appeared to work by chance only. My own project (mpv) relied extensively on this, but I observed some breakages even before the changes to the decoding APIs were made. Some audio decoders even outright crashed. My conclusion is: it usually worked, but couldn't be relied upon. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
