Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Greg_L_
Beginner
60 Views

Intel IPP vs Intel Media SDK - image resizing

Hi, 

I'm interested in understanding the differences between Intel IPP and Intel Media SDK in terms of image resizing.  I have a test application written in C# using IPP8.2 functions via P/Invoke to resize decompressed images in NV12.  This resizing is intended to be used to optimize the performance of a video pipeline, which ultimately renders to D3D9 surfaces (we are generally resizing down to a target render size that is smaller than the input resolution). I would like to understand if it's possible to use the Intel Media SDK to perform these resizing tasks.  The exact IPP8.2 functions I'm currently experimenting with are: 

ippiResizeYUV420GetSize, ippiResizeYUV420LanczosInit, ippiResizeYUV420GetBufferSize & ippiResizeYUV420Lanczos_8u_P2R.

Are there direct equivalents for these in the Intel Media SDK?  If so, can you summarise the performance differences for these kinds of operations between IPP and the Intel Media SDK?  

Thanks, Greg.

0 Kudos
1 Reply
Jeffrey_M_Intel1
Employee
60 Views

Performance in this case is hard to generalize.  It will be best to measure in your application on your HW.  Please keep in mind that Media SDK is designed for media pipelines.  It will work best when other stages are combined on the GPU.  The best case for this type of application would be if decode, resize, and render all occur on the GPU.  In this scenario, copying to CPU, resizing with IPP, then copying back for render would be significantly slower.  Alternately, if you're mixing CPU and GPU operations the cost to copy surfaces may turn out to be a bigger bottleneck than the time required to resize.  Another factor is turbo boost -- short bursts of activity like isolated resize may keep the GPU at its base frequency, where you won't see the full performance capabilities.  Converting the full pipeline to GPU may allow full "turbo" acceleration because the GPU is more consistently busy.

Reply