Media (Intel® Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools like Intel® oneAPI Video Processing Library and Intel® Media SDK
The Intel Media SDK project is no longer active. For continued support and access to new features, Intel Media SDK users are encouraged to read the transition guide on upgrading from Intel® Media SDK to Intel® Video Processing Library (VPL), and to move to VPL as soon as possible.
For more information, see the VPL website.

Intel IPP vs Intel Media SDK - image resizing



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

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.

0 Kudos