I am currently trying to integrate the UMC H.264 decoder into one of our products and I have noticed that the GetFrame method allocates as an output buffer a VideoData object whose buffer pitch is always a multiple of 64 bytes (I assume this is due to performance optimizations). This makes the integration more complicated as our interface expects a pitch equal to the actual width of the image.
So my goal is to modify the H.264 decoder to make it return VideoData buffers without right padding. My question is : where should I look at for modifications? Basically, where are the actual calls to decoding functions and the buffer allocation done?
edit : I use IPP 5.3
I am fairly experienced with IPP's codecs and modifying the code to suit my own requirements. After seeing your posts about the alignment and the 3:2 pulldown, I believe I can help you. You can contact me at jere AT dragonglobal DOT biz.
Meanwhile, I have found the instruction that does the alignment/padding :
umc_h264_dec_defs_yuv.cpp, line 187 :
nPitchLuma = align_value
LUMA_PADDING is 0 and DATA_ALIGN is 64.
nPitchLuma is later affected to the m_pitch_luma of a H264DecoderFrame, which is used to initialize the pitch of the luma plane of the output VideoData.
T align_value(size_t nValue, size_t lAlignValue = DEFAULT_ALIGN_VALUE)
~(lAlignValue - 1));
Well, simple enough, it rounds nValue to the nearest bigger multiple of lAlignValue (provided it is a power of two).
The question I try now to get an answer to is : why is this alignment needed?