H.264 decoder and image pitch

[billaj]

Hello,
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

Best regards,
Jean-Charles

[jere_jones]

Jean-Charles,

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.

Jere

[billaj]

Jere, thanks for your proposal for help :) , but I'd rather keep it on the forum, it may be of some help for others...

Meanwhile, I have found the instruction that does the alignment/padding :

umc_h264_dec_defs_yuv.cpp, line 187 :

nPitchLuma = align_value (lumaSize.width + LUMA_PADDING * 2, DATA_ALIGN);

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.

align_value is:

template inline
T align_value(size_t nValue, size_t lAlignValue = DEFAULT_ALIGN_VALUE)
{
return static_cast ((nValue + (lAlignValue - 1)) &
~(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?

[billaj]

Okay, I replaced the alignment value with 1 and I get a non-right-padded VideoData as hoped. Everything seems OK! I haven't compared decoding performance vs. the previous, 64-byte aligned version yet...

[billaj]

Further testing has been done with a 1-alignment value and the results are still correct.
Surprisingly, execution is about 3% faster without 64-byte alignment!