Media (Intel® oneAPI Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools from Intel. This includes Intel® oneAPI Video Processing Library and Intel® Media SDK.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

Intel IPP vs Intel Media SDK - image resizing

Greg_L_
Beginner
127 Views

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
127 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