From: Mikko H. <mik...@no...> - 2010-08-01 17:34:36
|
Hi all, 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. -- Mikko Hurskainen |