Hi,
I have 2 questions related to tiler memory space 2D buffers.
I am working on a project that utilizes video encoder on OMAP4 (H.264) using
OpenMax API.
In general, the encoder works as expected except that I am seeing a very
slow memcpy operation that copies input frame data to encoder’s buffers
(takes almost 100ms to copy 720p frame). I am relying on OpenMax to allocate
the input buffers (using OMX_AllocateBuffer). The same memcpy routine works
much faster when copying the same data into regular user-space allocated
buffers (malloc based). Considering that the encoder is supposed to work at
the rate of 30fps, spending 100ms on each frame is too much.
I understand that OpenMax allocates tiler 2D buffers using memory manager
and it appears that those buffers are non-cachable.
I have tried to map user-space allocated buffer into tiler memory space
(using MemMgr_Map) and then to copy frame data into the user-space memory
pointer. In this case memcpy works indeed faster (although still not as fast
as I would have hoped for), but I am seeing lots of artifacts in the encoder’s
output. I am assuming this could be related to caching issues with the
mapping.
My first question is: is there a way to be able to copy encoder input data
in a fast way – maybe there are specific requirements for allocating/mapping
encoder input buffers?
My second question is about tiler image rotation: what is the correct way
(if any) to be able to utilize tiler-based rotation on encoder’s input
buffers from user-space (only interested in right-angle rotations). I
understand that I need to calculate the correct tiler memory space offset
for the specific rotation degree that is required. Would I be able to access
the address from user-space and maybe even somehow ask the encoder to use
the rotated image instead of the original one?
Any information/hints will be greatly appreciated (or a sample test source
code).
Thank you,
Leo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
