Hi there,
I noticed that the nFilledLen field of OMX_BUFFERHEADERTYPE's are always twice as big as what's specified in OMX_[Use|Allocate]Buffer() calls, for the HDMI display buffers (or perhaps I should say the VFPC-DEI output buffers destined for the HDMI display).
For example, in the Capture Encode demo, running at 720p we have:
Frame width = 720
Frame Height = 1280
Frame Stride/Pitch = 2*720 = 1440
As done in the demo code, the HDMI display (422I) buffer size is then calculated as: 2 * 720 (frame stride) * 1280 (frame height) = 1843200. (See pAppData's nBufferSize for the HDMI display buffers)
However, if you print the pBuffer[In|Out]->nFilledLen value out in IL_ClientProcessPipeCmdETB() or IL_ClientProcessPipeCmdFTB(), you'll see that we have a value twice as big as our allocated buffer (3686400). I see that the buffer's nOffset field is 0, and the nAllocLen is what we specified in the Allocate/Use calls, plus a bit of what I assume is padding or metadata.
Could someone shed some light on this size discrepancy? I'm concerned that components might actually be clobbering neighboring memory. Perhaps I'm missing something with respect to the video format?
For reference, the above observations have been made using the Capture-Encode demo included in the EZSDK 5.03.01.15 release.
Thank you,
Jon
Hi,
It was an issue with dei component calculation of nFilledLen. It would not overwrite some other place though. We have rectified it already for next release. Thanks for pointing the same.
Regards
Vimal
Vimal,
Thank you for verifying this and letting me know about the fix.
Regards,