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
signature.asc
Description: OpenPGP digital signature
