[Bug 731274] New: Valid frames dropped after losing input signal with dvbsrc

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=731274
  GStreamer | don't know | 1.3.2

           Summary: Valid frames dropped after losing input signal with
                    dvbsrc
    Classification: Platform
           Product: GStreamer
           Version: 1.3.2
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: don't know
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: aurelien.zanelli at parrot.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Running the following pipeline (template) on RPi for instance

gst-launch-1.0 dvbsrc <modulation-params> ! queue max-size-buffers=600
max-size-time=0 ! tsdemux ! h264parse ! omxh264dec ! glimagesink

Remove the antenna during 30s and re-plug it will cause the next 30s valid
frames to be dropped by the omxdecoder and so no image will be displayed.

What happened ?
We begin with a good signal and video on the screen and pipeline run correctly.
After a while, for example at 0:01:00, we lost the antenna signal. So the
dvbsrc won't push data anymore but the pipeline clock keep going and we have
some data block in tsdemux, h264parse (not enough data to complete buffer) and
we can also have some frame into the decoder. Let's say these data are
timestamped with 0:01:00.
When the signal comes back, for example at 0:02:00, the tsdemux/h264parse and
the decoder will output the old timestamped frames. When the videosink received
these frames, it performs QOS on it and will return a jitter of 0:01:00 and a
timestamp of 0:01:00.
Then, the videodecoder base class will parse the QOS event and set it's private
variable earliest_time to timestamp + 2 * jitter + priv->qos_frame_duration = ~
0:03:00. earliest_time is used to calculate the next frame deadline.
So all frames between 0:02:00 and 0:03:00 which are valid and not late will be
considered by the videodecoder base class to be late.
With the omxvideodecoder implementation, frames too late are dropped
(http://cgit.freedesktop.org/gstreamer/gst-omx/tree/omx/gstomxvideodec.c#n1356).
In fact they are already too late when they are handled by omxdecoder class.

I upload a log of the example pipeline with
--gst-debug=omxvideodec:6,basesink:5,videodecoder:5,GST_QOS:5 on
http://www.darkosphere.fr/tmp/gstreamer/dvb-qos-signal-lost.log
In this log, the gap occurs between 0:00:11.545868000 and 0:00:42.025934000


As a temporary workaround, I disabled the frame dropping in omxvideodec and I
get instantaneously the stream after a gap.

However I don't think the problem is especially in gst-omx nor in dvbsrc. I
think it can happen with all live pipeline and decoder which handle QOS. That's
why I set "don't know" as category.

Do you have any ideas and hints on how to solve this issue ? I look at GAP
event, but I don't succeed :)

-- 
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.