[Bug 767499] Spatial Resolution Change Causes Playback Freeze

[GStreamer (GNOME Bugzilla)]

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

Julien Isorce <julien.isorce at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |julien.isorce at gmail.com

--- Comment #5 from Julien Isorce <julien.isorce at gmail.com> ---
Hi Sam, I remember that the pause was maximum 1 sec. This only happens when
using OMX_UseBuffer(or OMX_UseEGLImage) because the gstomxvideodec wraps the
downstream pool in its own buffer pool see
https://cgit.freedesktop.org/gstreamer/gst-omx/tree/omx/gstomxbufferpool.c#n353
. So before the decoder can reset its resolution it needs all the buffer to
return to its pool.

The decoder cannot directly call 'gst_buffer_pool_acquire_buffer' on the video
sink 's buffer pool, otherwise it might acquire a buffer that does not match
what the decoder has last used/filled.

So it affects zero copy (because OMX_UseEGLImage) and OMX resize/convert
component (because OMX_UseBuffer
https://bugzilla.gnome.org/show_bug.cgi?id=722686).
(This problem does not affect cases with OMX_AllocateBuffer, but this is much
slower so not practical in most of the cases)

There is potentially a solution which is to use the new
'gst_video_decoder_allocate_output_frame_with_params' I added recenlty which
allows to pass some params (instead of
https://cgit.freedesktop.org/gstreamer/gst-omx/tree/omx/gstomxvideodec.c#n1475
).
This will allow to pass an ID by suclassing GstBufferPoolAcquireParams. So that
the downstream pool can return the matching buffer for the given ID instead of
returning the next buffer from its queue.
At least it should save the time it takes currently to reclaim the buffers
which are still in use downstream from the decoder point of view. With this
solution the decoder does not need to wait since it does not own them.

Btw, were you testing in rpi2 or rpi3 ?

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