[Bug 774654] Flushing can hang if output port queue of pending buffers is empty

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from minfrin at sharp.fm ---
Simple workaround:

diff --git a/omx/gstomxvideodec.c b/omx/gstomxvideodec.c
index 1e7d436..6c07c9f 100644
--- a/omx/gstomxvideodec.c
+++ b/omx/gstomxvideodec.c
@@ -928,6 +928,7 @@ gst_omx_video_dec_reconfigure_output_port (GstOMXVideoDec *
self)

   /* At this point the decoder output port is disabled */

+goto skip;
 #if defined (USE_OMX_TARGET_RPI) && defined (HAVE_GST_GL)
   {
     OMX_STATETYPE egl_state;
@@ -1106,6 +1110,7 @@ gst_omx_video_dec_reconfigure_output_port (GstOMXVideoDec
* self)
     self->eglimage = FALSE;
   }
 #endif
+skip:
   port = self->dec_out_port;

   /* Update caps */

Seems the GST_CAPS_FEATURE_MEMORY_GL_MEMORY support inside
gst_omx_video_dec_reconfigure_output_port() breaks dynamic resolution changes.

gst_omx_video_dec_reconfigure_output_port() is called on dynamic resolution
callbacks, but instead of reading the dynamic resolution from the callback, we
hardcode the resolution instead to GLMemory+RGBA, then RGBA, completely blowing
away the resolution we just received.

I am not sure what the fix is, as I am not 100% sure what the GLMemory code is
trying to do. It looks like this code is in the wrong place, we should be
negotiating GLMemory support, not forcing GLMemory support downstream surely?

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