dvbsrc: Valid frames dropped after losing input signal, with tsdemux ! h264parse ! omxh264dec ! glimagesink

Submitted by Aurélien Zanelli

Link to original bug (#731274)

Description

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 :)