Bug#879673: ffmpeg 3.4 API compat layer not 100% backwards compatible

[James Cowgill]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-3.4-compat-decode.debdiff
Type: text/x-patch
Size: 2076 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20171107/630bf78f/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20171107/630bf78f/attachment-0001.sig>