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

[James Cowgill]

Control: clone -1 -2 -3
Control: reassign -2 gst-libav1.0 1.12.3-1
Control: notforwarded -2
Control: severity -2 important
Control: affects -2 - src:kodi src:gst-libav1.0
Control: retitle -2 gst-libav1.0: incorrect use of drain packets in avcodec_decode_* api
Control: reassign -3 kodi 2:17.3+dfsg1-5
Control: notforwarded -3
Control: severity -3 important
Control: affects -3 - src:kodi src:gst-libav1.0
Control: retitle -3 kodi: incorrect use of drain packets in avcodec_decode_* api

Hi,

On 07/11/17 17:50, James Cowgill wrote:
> 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).

I've applied a slightly modified version of the patch I posted before. I
also posted it upstream, but I don't think they like it at the moment.

In any case, both gst-libav1.0 and kodi incorrectly use the
avcodec_decode_* apis by expecting them to work properly after they have
been drained. You must flush the codec after draining otherwise it won't
work (as can be seen here).

Thanks,
James

-------------- 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/20171109/186f2741/attachment.sig>