[Bug 796334] New: avdec_h264 looses reference frames after lost packages

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796334

            Bug ID: 796334
           Summary: avdec_h264 looses reference frames after lost packages
    Classification: Platform
           Product: GStreamer
           Version: 1.14.1
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-libav
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: m.olbrich at pengutronix.de
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Since the update to ffmpeg n3.4.1 (1.12.0-39-g829b269e1ef3) avdec_h264 handles
packet loss badly.

This pipeline shows this nicely:
gst-launch-1.0 videotestsrc pattern=ball ! x264enc key-int-max=60 ! \
  rtph264pay ! identity drop-probability=0.01 ! queue ! rtph264depay ! \
  avdec_h264 ! autovideosink

With gst-libav before the mentioned commit, it looks like the last decoded
frame is uses as a reference frame. This results in minor artifacts but the
video is still recognizable. 
After this commit an empty frame is a reference frame. As a result the video is
a grey mess until the next I-Frame.

I tracked this down to two relevant commits in ffmpeg:
061a0c14bb57 decode: restructure the core decoding code
d8d1689f929c avcodec/decode: reset codec on receiving packet after EOF in
compat_decode

With the first one and without the second one playback is completely broken. If
I back-port the second commit onto the first one, then I get the error
described above. All commits before the first one are good.

The commit message of the second commit looks suspicious:
[...]
To restore some compatibility, reset the codec if we receive a new non-drain
packet using the old API after draining has completed. While this does
not give the same behaviour as the old API did, in the majority of cases
it works and it does not require changes to any other part of the decoding
code.
[...]
Maybe we need to switch to the new API?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.