Unexplained freeze/hang from gst-omx omxh264enc on Raspberry Pi 3

[Graham Leggett]

On 15 Nov 2016, at 3:34 AM, Graham Leggett <minfrin at sharp.fm> wrote:

> - What does "Draining component” do? It appears to be called from gst_omx_video_enc_finish(), but I cannot figure out why finish is being called on the encoder or what triggered it.
> 
> - Are there any known bugs in omxh264enc that would cause it to stop encoding for any reason (as opposed to being temporarily degraded but still running).

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?

Regards,
Graham
—

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3240 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161120/d637f9dd/attachment.bin>