Current recommendation is to “piggy bag” the metadata along with the data buffer in OMX_BUFFERHEADERTYPE, assuming the meta-data starts at the next 4 byte aligned pointer. This is following issues, especially when the data is 2D in a larger buffer (or) when the buffer is shared between 2 processors.

Issues:
•	Many times the way data buffers are accessed is different from the way meta-data is accessed. For example, in case of video buffers, the video data can be accessed via DMA but the meta-data is typically accessed via CPU (commonly through cache). In a multi-core platform (typically the case with mobile processors these days), the meta-data accessed via cached must start at a cache-line boundary and not immediately after the data. 

•	In case of meta-data following 2D data in a larger buffer, should the meta-data be written upto width of 2D buffers or can it go till the stride (this could be an issue as there can be valid data for other components) 

•	Data buffers can be special: For example frame buffers (of a certain resolution). Adding meta-data to the same buffer complicates the buffer management by adding 2 different data requirements to the same buffer 

•	If 2D data buffers are to be read after a particular rotation (say 90), then the meta-data would not follow at the end of the currently accessed buffer but to the sides. This requires added precaution to be taken by users of 2D data with meta-data 

•	(Minor) Meta-data size requirement has to be added to nBuffersize. This needs recalculation due to changes in meta-data configuration (or) changes in buffer sizes 

An example solution:
•	Add new configurations to query the size of meta-data given the configuration of which meta-data types are enabled currently 
•	In OMX_BUFFERHEADERTYPE, add 2 fields for pointing to meta-data buffer (additional pMetaData and nMetaDataSize). 
•	The tunneled component or IL client which allocates data buffers, could also allocate & free the meta-data buffer, querying the other components requirements 
•	Keep the current mechanism of packing the various extra-data one after another in the pMeta-Data buffer, rather than the pBuf. This can always be a 1D buffer (i.e. without strides (or) Width to follow)