[Bug 738472] New: gstvideodecoder: a/v sync issues with corrupted stream

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738472
  GStreamer | gst-plugins-base | git

           Summary: gstvideodecoder: a/v sync issues with corrupted stream
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: matej.knopp at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


The reordered_output behavior of gstvideoencoder seems to be causing issues for
us with broken h.264 stream (decoded using libav)

The problem is that at some point, the decoder returns one decoded frame from
past (that has PTS lower than last frame PTS). gstvideodecoder sees this,
thinks all timestamps are broken and starts interpolating from that PTS.

Example

PTS-IN:   1    PTS-OUT: n/a
PTS-IN:   2    PTS-OUT: 1
PTS-IN:   3    PTS-OUT: 2
PTS-IN:   4    PTS-OUT: 3
PTS-IN:   5    PTS-OUT: 4
PTS-IN:   6    PTS-OUT: none - decoding problem
PTS-IN:   7    PTS-OUT: none - decoding problem
PTS-IN:   8    PTS-OUT: none - decoding problem
PTS-IN:   9    PTS-OUT: 8

// at this point the decoder returns one frame from past; I'm not sure why this
happens, the frame should obviously be discarded, but it does;
// gstvideodecoder will interpolate all following timestamps from this one
PTS-IN:  10    PTS-OUT: 5

PTS-IN:  11    PTS-OUT: 10

If I make sure that the PTS is monotonous (by comparing it to previous value)
there are no issues; I understand what the behavior is for, but maybe it could
be optional?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.