[gst-devel] Gst-omx buffer renegotiation problem

Felipe Contreras felipe.contreras at gmail.com
Tue Aug 3 13:25:40 CEST 2010


Hello Mikko,

On Sun, Aug 1, 2010 at 7:59 PM, Mikko Hurskainen
<mikko.hurskainen at notava.com> wrote:
> I ran into a buffer renegotiation problem when trying to use gst-omx.
> Since I didn't found any other mailing list for gst-omx and the problem
> might be relevant for other gstreamer components as well I am posting my
> question here.
>
> So the problem is that when using the gst-omx video decoding the buffers
> are allocated automatically. The gst-omx queries from the component that
> how many and which size buffers it should allocate. The omx component
> replies to allocate very few and very small buffers. With those buffer
> sizes the decoding cannot proceed (input 2 buffers of size 256 and
> output 4 buffers of size 256).
>
> When gstreamer does the preroll and the component starts decoding it
> posts settings changed event that contains the correct sizes of the
> buffers for input & output. The settings changed event is handled in the
> base_video_dec class, but only for resolution & color format.
>
> So far I've identified two solutions:
>  - Always at the beginning allocate a big enough buffer, however, this
> solution has a drawback when dealing with HD resolutions
>  - Implement buffer reneallocation into the base_video_dec class.
>
> The buffer reallocation seems to be the way to go, but before jumping
> into this I would like to ask if anybody else has encountered the same
> problem with some non-omx codec and how it was handled ? For example
> which state the gstreamer pipeline needs to be and so on ? Normally of
> course media file container provides these values, but sometimes that
> might be broken and/or unavailable.

Well there's a third solution:
 * Don't allocate buffers in the first place if you don't know what
the final size would be

So, in gst-dsp that means we have to delay the DSP algorithm
initialization until we know the width and height of the clip. In
gst-openmax this would mean to delay the port buffer allocation, and
therefore the switch to Idle state.

IIRC in the past the switch to Idle state was synchronized with
GStreamer states, but not any more. So if your component is updating
nBufferSize when the framesize is updated, then everything should work
fine.

-- 
Felipe Contreras




More information about the gstreamer-devel mailing list