multiple I/O buffers

How can we support codecs which need multiple input/output buffers of different sizes?
OMX doesnt have features required to handle input buffers with different sizes.
One solution could be, allocating required number of buffers all with max buffer size.
But this will not be optimal, especially when only one buffer is big and other buffers are comparatively small.
Is there any other option?


Which codec are you having problems with?

How many buffers do you really need?
If small buffers are being sent, then you can always copy the (short) contents into an internal buffer, releasing the large IL buffer for reuse.



I was thinking for some hypothetical codec for eg. multichannel encoder taking input from different channels or an AV creater or some split codec in which 2nd half of codec takes input in multiple buffers. In API’s like TI’s XDM there is a provision for multiple input/output buffers. There is nothing like that in OMX.

Wouldn’t each channel have its own input port? You could then negotiate the buffer sizes on each port.

I assume that you mean multiple buffers of different maximum sizes? If so, you can add a copy into some internal memory to avoid having many, large, buffers for the tunnel. Given that IL is very flexible on how much compressed data you must put in each buffer, you will need some internal buffering.

Finally, if you are supplying all the components, you may want to consider proprietary communication. Here you can do the data transfer how you wish.




I have seen the same problem with video frames. For example, according to the IL spec in section 4.2.3, if we support the OMX_COLOR_FormatYUV420SemiPlanar format, the two planes must be split into two seperate buffers, each of which has it’s own buffer header. This makes sense as otherwise the start of the CbCr data has to be implied from the size of the image and there is no way to force alignment of the CbCr plane.

However, when a port provides information on the size of the buffer required, what does it do? If it gives the size in bytes of the Y plane, then does the Client know that the CbCr plane is half this size? If the Client always allocates buffers at the size of the Y plane, there will be a big memory overhead (we’re talking HD here).

The only solution I can see is via UseEGLImage, where the OMX buffer header information on the format is ignored. Any ideas?