Intel® Integrated Performance Primitives

ippiResizeLinear_8u_C1R reads past the end of the source buffer


I'm trying to resize an image using ippiResizeLinear_8u_C1R. When I have application verifier enabled, it's telling me that this function is reading past the end of the source buffer. This only seems to occur when the output dimensions are odd. Is this a known issue? I couldn't find any documentation that indicates the dimensions need to be multiples of 2.

Here is the input format/sizes I'm using:

Input: YUV420 610x310

Output YUV420 305x155




How to operate warp affine linear with source ROI


I'm trying to upgrading my code to 2017 IPP composer, in the old interface (2015 composer) there was a support for a native source and destination ROI, 

In the new interface, I could not find source ROI support, however I did found a destination ROI support on the 6th parameter of the

ippiWarpAffineLinear_*** function. 

I couldn't find GetAffineSrcRoi function useful for my use. 

How to use warp affine functions with source ROI support ? 




How the frequencies are normalized for ippsFIRGenBandpass_64f

Dear all,

I would like to use IPP band pass filter function

ippsFIRGenBandpass_64f(rLowFreq, rHighFreq, taps, tapslen, ippWinBartlett, ippTrue, pBuffer) )

However rLowFreq and rHighFreq are normalized frequency between [0,0.5]. Could you confirm how the frequency normalization should be done? Is it

f / fmax / 2

In my calculation window?

Thanks and regards,


What does LGLOOPgas_2 mean

Hi Intel Engineers,

I am now trying to use IPP 2018 Beta Updata1 to replace IPP 7.0.

From the vTune Memory Access, a brand new function (called LGLOOPgas_2) came up, which consumes the most clockticks.

I had never seen this function from IPP 7.0, and could not find any related information about it from the internet. Due to its high consuming of clockticks, high CPI Rate(10.966), and high Back-End Bound(95.0%), I am curious about what this function is doing.

High CPU usage in linux for MPEG4 and H264 encoders


We see high cpu usage for MPEG4 and H264 encoding in Linux when compared to Windows. We are using IPP 2015.6.233 with 8.0 UMC samples.

System: Pentium CPU G4400 @3.30GHz x 2 with Intel HD Graphics 510. 

Ran umc_video_enc_con (with usleep for 142 milliseconds to process 7 FPS) on both Windows and Linux with input as YUY2 file.

Single Thread


1% cpu for MPEG4, Encoding: 2.18 (192 FPS), Conversion 0.08

3% cpu for H264, Encoding: 14,03 (30 FPS), Conversion 0.10

unresolved typeref token (01000024) for 'FFTSpec_C_64fc'


I'm calling the function ippsFFTInit_C_64fc() with a double pointer to IppsFFTSpec_C_64fc as one of the function parameters.

I'm facing this annoying warning - Warning LNK4248 unresolved typeref token (01000024) for 'FFTSpec_C_64fc'; image may not run.

I understand that I get this warning due to the fact that IppsFFTSpec_C_64fc  is a typedef of struct FFTSpec_C_64fc (ipptypes.h) and struct FFTSpec_C_64fc has no definition.

Division by infinity problem


I am using IPP 2017 update 3 as single-threaded static library on Visual Studio 2015. My runtime environments are:

  • Intel® Core™ i7-3770 CPU @ 3.40GHz on Windows 7,
  • Intel® Xeon® CPU E5-1650 v4 @ 3.60GHz on Windows 10.

I found a problem with division of finite number by infinity (like 1/inf) with the following functions:

  • ippsDiv_32f,
  • ippsDiv_32f_I,
  • ippiDiv_32f_C1R,
  • ippiDiv_32f_C1IR

As the result of operation I receive NaN instead of 0.

Subscribe to Intel® Integrated Performance Primitives