Where can I get more details regarding an issue fixed in IPP 7.02

[Emmanuel_W_]

Hi,

The following item is mentionned in the list of issue fixed in IPP 7 update 2.

DPD200137548 H.264 Decompression on x64 is significantly slower compared to x32.

It sounds like a serious issue but there is no detail about the fix or situation in which the problem happen.

-Is this a sample fix, a library fix or both ?
-Is this an issue in IPP 6.1 or was this a bug introduced in IPP 7 ?
-Is this an issue with any H.264 stream or only specific profiles ?

Thanks

[Vladimir_Dudnik]

Hello,

this issue was related to the level of optimization for primitive functions. No H.264 sample code changes involved.

Regards,
Vladimir

[Emmanuel_W_]

Great thanks, and I suspect that the less optimized code was also in IPP 6.1.

[PaulF_IntelCorp]

Yes, the optimization problems also existed in the 6.1 code.

[Emmanuel_W_]

I have run several tests using sample version 6.1 and IPP 6.1 vs 7.02 and can't find any difference in term of speed.

[Vladimir_Dudnik]

Have you compared performance on IA32 vs Intel64 architectures?

Vladimir

[Emmanuel_W_]

No I just tested the two versions on 64bits expecting to see an improvment (no 32 bits system on hands).

Emmanuel

[Vladimir_Dudnik]

Hi Emmanuel,

a lot of factors may affect performance comparison. But for this particular issue we have a confirmation that it was fixed from customer who has intially reported about it. Below are performance data on IPP functions

	IPP 6.1		IPP 7.0.2
	intel64	intel64	ia32
ippiReconstructLumaIntra8x8_H264High_32s16u_IP1R	2.56	0.385	0.574
ippiReconstructChroma422Inter4x4_H264High_32s16u_IP2R	0.897	0.158	0.19
ippiDecodeCAVLCCoeffs_H264_1u32s	0.528	0.467	0.445
ippiReconstructChroma422Intra4x4_H264High_32s16u_IP2R	0.14	0.079	0.061

Regards,
Vladimir

[Emmanuel_W_]

Thanks Vladimir,

I didn't use 8x8 transform or 422 sampling in my tests so that makes sence ;)

Emmanuel