Control: affects -1 src:kodi src:gst-libav1.0
Control: tags -1 patch Hi, On 24/10/17 09:52, Sebastian Dröge wrote: > Package: ffmpeg > Version: 7:3.4-1 > Severity: serious > > Hi, > > ffmpeg 3.4 comes with a new decoding API (among other things), and > provides a compatibility layer around that for the old API. > Unfortunately this compatibility layer is apparently not 100% backwards > compatible or buggy. It breaks at least h264 decoding with gst- > libav1.0, but then probably also breaks other packages. > > gst-libav upstream bug can be found here: > https://bugzilla.gnome.org/show_bug.cgi?id=789193 > > We'll try to port over to the new API but it looks like some effort, > and even independent of that the compatibility layer should either be > fixed or the soname of the libraries has to be updated. Unfortunately there doesn't seem to have been a lot of activity on the upstream bug report from FFmpeg themselves. Based on what I can infer from the source code, I think there is no API breakage here. The documentation on draining packets in the old API is pretty poor and it "worked" with ffmpeg < 3.4 so people started using it that way. However, I think that even under the old API, drain packets can only be sent at the end of a stream. This seems to make the most sense and aligns with new the API (where the documentation does say that this is required). I think the best solution is to apply the attached workaround for the time being to the Debian package. The workaround will call avcodec_flush_buffers automatically when it detects that a data packet has been sent to avcodec_decode_* after the codec has been completely drained. This allows gst-libav1.0 and kodi (which I also discovered does this) to play video again. I am wondering why gst-libav1.0 needs to drain the code at every discontinuity in the stream? I would have thought there are two separate cases here: seeking where you want to reset the codec, and dropped packets where you allow the codec itself to fix the stream (as best it can). Thanks, James
diff --git a/debian/patches/0003-reset-codec-after-eof.patch b/debian/patches/0003-reset-codec-after-eof.patch new file mode 100644 index 00000000..a8bb7692 --- /dev/null +++ b/debian/patches/0003-reset-codec-after-eof.patch @@ -0,0 +1,34 @@ +Description: lavc: reset codec on receiving packet after EOF + In ffmpeg 3.4, the deprecated avcodec_decode_* APIs were reworked so that they + called into the new avcodec_send_packet / avcodec_receive_frame API. This had + the side effect of prohibiting sending new packets containing data after a + NULL packet. In the new API, it is documented that a NULL packet means EOF. + . + While the documentation is sparse in this area. It seems that a NULL packet + also meant EOF in the old API, but since it was unclear and worked, a few + applications assumed that it was ok to to continue sending data after an EOF, + and subsequently broke with ffmpeg 3.4. + . + This patch adds a workaround to the old API which will reset the codec + (allowing new data) if a packet is received after an EOF. Hopefully this + allow these applications to continue to work with newer ffmpeg. +Author: James Cowgill <jcowg...@debian.org> +Bug: https://trac.ffmpeg.org/ticket/6775 +Bug-Debian: https://bugs.debian.org/879673 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/libavcodec/decode.c ++++ b/libavcodec/decode.c +@@ -753,6 +753,12 @@ static int compat_decode(AVCodecContext + + av_assert0(avci->compat_decode_consumed == 0); + ++ if (avci->draining_done && pkt && pkt->size != 0) { ++ av_log(avctx, AV_LOG_WARNING, ++ "Got unexpected packet after EOF. Resetting codec and continuing...\n"); ++ avcodec_flush_buffers(avctx); ++ } ++ + *got_frame = 0; + avci->compat_decode = 1; + diff --git a/debian/patches/series b/debian/patches/series index bb700bb6..4fe4a0d2 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,2 +1,3 @@ 0001-arm-thumb2-blx.patch 0002-arm-Check-for-have_vfp_vm-instead-of-have_vfpv3.patch +0003-reset-codec-after-eof.patch
signature.asc
Description: OpenPGP digital signature
