GNOME Bugzilla – Bug 731274
dvbsrc: Valid frames dropped after losing input signal, with tsdemux ! h264parse ! omxh264dec ! glimagesink
Last modified: 2018-11-03 13:23:58 UTC
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 :)
Hah, interesting bug this. I guess it shows that that formula is really a big bogus, although I would still say that the problem is with the intermediary elements not either outputting the data earlier or dropping it. Maybe we shouldn't do QoS in the video decoder at all in live pipelines.
(In reply to comment #1) > Hah, interesting bug this. I guess it shows that that formula is really a big > bogus, although I would still say that the problem is with the intermediary > elements not either outputting the data earlier or dropping it. I don't think the qos formula is in fault here. It's just decoder which output old frames causing the sink to think it is late. > Maybe we shouldn't do QoS in the video decoder at all in live pipelines. Doing this will also remove the 'real' QOS event, ie performance issue... I wonder about using the DISCONT flags. Since live src doesn't have received data for a while, it could mark the discont and the decoder/intermediate element may flush to avoid sending old video data to sink.
Can you retest how things behave with a more recent GStreamer? tsdemux and h264parse should always output as much data as possible, and when they get a DISCONT on the input they should clear out any partial data stuck internally. However, I suspect the interesting question is what happens on the decoder side, since it could be expected that some old frames are only output later. And the source probably also doesn't output any GAP events or such.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/153.