GNOME Bugzilla – Bug 741856
omxvideodec: add a hack to workaround egl_render signalling EOS prematurely
Last modified: 2016-12-22 12:48:21 UTC
Created attachment 293178 [details] [review] patch The egl_render component of the broadcom (raspberry pi) implementation has a bug that causes it to signal OMX_BUFFERFLAG_ENDOFFRAME | OMX_BUFFERFLAG_EOS at some point earlier than the actual end of the file. After that, violating the OMX specification, it continues pushing out some more buffers without any further indication of when it has really finished. This patch adds a hack that causes gst-omx to wait a bit more time after egl_render has signalled EOS before pushing EOS further to the gstreamer video sink. In case a new buffer arrives at this point, omxvideodec pushes it normally downstream and waits again. If this timeout passes without any new frame from egl_render, then EOS is properly sent to the video sink too.
Perhaps this could be fixed upstream instead via detailed report to https://github.com/raspberrypi/userland/issues ?
Actually https://github.com/raspberrypi/firmware/issues might be more appropriate; after looking I mostly just find MMAL processing delivering the EOS ( https://github.com/raspberrypi/userland/blob/master/interface/mmal/components/avcodec_video_decoder.c#L416 ), so likely firmware sends it wrong (but didn't look too hard)
Comment on attachment 293178 [details] [review] patch Looks good but doesn't apply to master.
Does someone with a Pi can rebase and validate the attached patch ?
Created attachment 341169 [details] [review] omxvideodec: add a signals-premature-eos hack for egl_render egl_render seems to have a bug and signals EOS before it has finished pushing out all data; this hack simply makes acquire_buffer() wait a bit more before signalling EOS, in case egl_render decides to spit out some more data.
Rebased and validated.
Created attachment 341170 [details] [review] omxvideodec: add a signals-premature-eos hack for egl_render egl_render seems to have a bug and signals EOS before it has finished pushing out all data; this hack simply makes acquire_buffer() wait a bit more before signalling EOS, in case egl_render decides to spit out some more data.
Review of attachment 341170 [details] [review]: Makes sense to me. Ugly but... :) Did you also file a bug against the RPi firmware for this? Please do and link this here. Just a minor thing needs to be changed: ::: omx/gstomx.h @@ +49,3 @@ + * out all of its buffers. Happens with egl_render on the rpi. + */ +#define GST_OMX_HACK_SIGNALS_PREMATURE_EOS G_GUINT64_CONSTANT (0x0000000000000400) You also want to add a mapping from a gstomx.conf string to this enum in gstomx.c
(In reply to Sebastian Dröge (slomo) from comment #8) > Review of attachment 341170 [details] [review] [review]: > > Makes sense to me. Ugly but... :) > Did you also file a bug against the RPi firmware for this? Please do and > link this here. > I'm using some rather old kernel/firmware/userland and didn't have the time to check with newer versions so I haven't filled a bug upstream. Sorry about that :)
Created attachment 341617 [details] [review] updated patch
Comment on attachment 341617 [details] [review] updated patch Looks good, but please file a bug against RPi before merging this.
commit 05b137a256f0e90926c76b0c8b76f16e35ccc65c Author: George Kiagiadakis <george.kiagiadakis@collabora.com> Date: Thu Dec 1 18:23:50 2016 +0100 Add a signals-premature-eos hack for egl_render egl_render seems to have a bug and signals EOS before it has finished pushing out all data; this hack simply makes acquire_buffer() wait a bit more before signalling EOS, in case egl_render decides to spit out some more data. https://bugzilla.gnome.org/show_bug.cgi?id=741856