[Bug 774600] mpegtsdemux: Pipeline hang on lossy transport stream

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from minfrin at sharp.fm ---
Some progress.

The hang turned out to be a patch I had added to stop gst-launch-1.0 from
exiting without it being asked to. What was really happening was the pipeline
was returning EOS on the live stream and exiting early before being asked to.

When a stream comes to EOS, gst_omx_video_dec_drain() is called to request the
graphics card empties all outstanding buffers. To drain the card, the
OMX_BUFFERFLAG_EOS flag is set on the buffers entering the card. This in turn
causes the GST_OMX_ACQUIRE_BUFFER_EOS status to be returned from
gst_omx_port_acquire_buffer(), which causes the code to follow a path that on
first invocation returns GST_FLOW_OK, but on subsequent invocations returns
GST_FLOW_EOS.

However, in the live streaming of unreliable streams case where a discontinuity
is encountered, we also call gst_omx_video_dec_drain() to empty the graphics
card before trying to start decoding from scratch after the discontinuity. On
this code path there is obviously no intention to shut the stream down with
EOS, but that’s ultimately what is happening. After a discontinuity, during
gst_omx_video_dec_drain(), the code is returning GST_FLOW_EOS when it should
not, causing the stream to be shut down prematurely.

The workaround is this:

diff --git a/omx/gstomxvideodec.c b/omx/gstomxvideodec.c
index 6baaa48..5a5998c 100644
--- a/omx/gstomxvideodec.c
+++ b/omx/gstomxvideodec.c
@@ -1568,7 +1569,8 @@ eos:
       gst_pad_pause_task (GST_VIDEO_DECODER_SRC_PAD (self));
     } else {
       GST_DEBUG_OBJECT (self, "Component signalled EOS");
-      flow_ret = GST_FLOW_EOS;
+      flow_ret = GST_FLOW_OK;
+//      flow_ret = GST_FLOW_EOS;
     }
     g_mutex_unlock (&self->drain_lock);

I am looking for some guidance on the real fix. Am I right in understand that
GST_FLOW_EOS is the job of the parent video encoder class, and that
gstomxvideodec.c has no business trying to return a GST_FLOW_EOS of it’s own?

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