chore(deps): update dependency intel/libvpl to v2023 - autoclosed

[renovate]

This PR contains the following updates:

Package	Update	Change
intel/libvpl	major	2.10.1 -> v2023.4.0

---

Release Notes

intel/libvpl (intel/libvpl)

v2023.4.0

Compare Source

Added

• oneVPL API 2.10 support
• New command line parameters to sample_multi_transcode for setting
  B Frame QP Offsets based on Pyramid Level
• New command line parameters to the sample_vpp tool to enable video signal
  information
• New APIs for importing and exporting shared surfaces
• New APIs for string-based parameter configuration

Removed

• Environment module support
• Unused files and folders

Fixed

• NV12 wayland render for MTL
• Buffer starvation when wayland window is moved
• Missing profile strings in vpl-inspect tool
• Rdrm to use card node instead of render node
• Rdrm tile4 selection based DRM/KMS query
• Rdrm NV12 and P010 render for MTL

Changed

• Directory layout and name of dispatcher directory
• Location of image files used by documentation
• Runtime library search path to remove current directory

v2023.3.1

Compare Source

Added

• Three new command line parameters to the sample_multi_transcode tool to enable
  video quality tuning for different use cases.
• New command line parameter to the sample_multi_transcode tool to enable
  adaptiveCQM control

Removed

• Outdated docker files

Fixed

• Unsafe calling of SetCurrentDirectory during MFXEnumImplementations
• Parameter parsing in sample_vpp tool

v2023.3.0

Compare Source

Removed

• USE_ONEAPI_INSTALL_LAYOUT build shortcut
• '-sw' option from examples

Added

• New MFXSetConfigFilterProperty property: mfxExtendedDeviceId.RevisionID

Fixed

• Fix HDR luminance value
• Handling of special cases of CMAKE_INSTALL_PREFIX
• X11 rendering corruption issue
• Intel® Distribution of OpenVINO™ Toolkit installation steps in vpl-infer README
• Intermittent Sample_multi_transcode segfault on Wayland

Changed

• quick-start scripts to be more simple and easy to use

v2023.2.1

Compare Source

Added

• Documentation on security policy and vulnerability reporting process

Removed

• Fix for VPP processing for YUV input

v2023.2.0

Compare Source

Added

• oneVPL API 2.9 support
• Perceptual encoding prefilter option to sample_multi_transcode

Fixed

• VPP processing for YUV input
• Sample_multi_transcode segfault on wayland
• Missing prerequisites in vpl-infer README

Changed

• vpl-infer Dockerfile and Linux setup steps to better align with https://dgpu-docs.intel.com/

Removed

• dpcpp-blur example

v2023.1.3

Compare Source

Added

• New tutorial on transitioning from Media SDK to VPL replaces hello-createsession
• More logs in sample tools to inform correct parameters for hyper encode mode

Fixed

• vpl-infer README.md to specify python version supported by OpenVINO™ toolkit
• Printing incorrect library information of sample tools
• Issues discovered from static analysis

Changed

• README.md and INSTALL.md to clarify setup steps

v2023.1.2

Compare Source

Added

• Instructions on how to use vpl-infer with official Intel® Deep Learning
  Streamer (Intel® DL Streamer) docker images by platform
• Support for zero-copy to vpl-infer example on Windows

Fixed

• vpl-infer Dockerfile failing to work in iGPU (Gen12) and to work with recent
  OpenVINO™ toolkit repository label change
• Warnings reported by Clang
• Hardening flags being incorrectly set on Linux executables

Changed

• Example directory names to clarify API level used
• vpl-infer to support OpenVINO™ toolkit 2022.3.0
• Version of GoogleTest to 1.12.1
• Compilation flags to enable Control Flow Guard on Windows

v2023.1.1

Compare Source

Added

• Help screen listing valid options for vpl-inspect
• YUV400 option for JPEG encoding with sample_encode
• Build option --disable_experimental to build with ONEVPL_EXPERIMENTAL disabled

Changed

• Session creation example to request a minimum API version

v2023.1.0

Compare Source

New in this release (since 2023.0.0)

Added

• oneVPL API 2.8 support
• New infer sample
• xdg_shell for weston10

Fixed

• NOT_ENOUGH_BUFFER error when HRD off in ExtBRC
• Legacy tools using x86/x86_64 specific assembler code
• Pkg-config files not installing in correct location in cross compilation
  scenarios

v2022.2.0

Compare Source

New in this release

Added

• Support for 2.7 API
  • GPU copy improvements:
    • Experimental DeviceCopy option for GPU-accelerated surface copying.
    • Selection of host or device responsible for the memory copy between host and device.
• MFX_FOURCC_XYUV FourCC for non-alpha packed 4:4:4 format.
• Notice to mfxFrameSurfaceInterface::OnComplete to clarify when library can call this callback.
• Pass through extension buffer to mfxInitializationParam via config filter property.
• Interface to get statistics after encode to Experimental API
• Support for Alder Lake N and Intel® Data Center GPU Flex Series (formerly Arctic Sound-M).
• Added Linux system_analyzer tool for improved runtime environment visibility.

Changed

• sample_multi_transcode to support HDR 3DLUT, SDR->HDR, VDSFC color conversion, improved tracer and latency measurement, AV1 temporal layers, HVS denoise.

Depreciated

• Support for Microsoft Visual Studio* 2017
• Current C++/Python preview APIs. (A different direction will be taken in future releases.)

Fixed

• Multiple SYCL deprecation warnings when compiling dpcpp-blur

• Sample readmes out of sync with current cmake and docker

• Not turning off tools/examples build when BUILD_DISPATCHER_ONLY=ON

• Tools failing to build on SLES if ENABLE_WAYLAND=ON

• Build fails against libva installed at custom location

• License reported by CPU implementation not matching compile

• Unclear error when advanced-decvpp-infer runs on unsupported platform

• Incomplete Linux instructions for dpcpp-blur sample

• Outdated OpenVINO path in interop Samples README

• dpcpp-blur sample not returning clear error when build attempted on unsupported operating systems

• MFXEnumImplementation not returning MFX_ERR_NOT_FOUND on non-Intel systems

• Sample_multi_transcode reporting error when multiline parfile uses -sw flag

• Legacy tools requiring libva-drm.so.2 when run in SW mode.

• Inability to enable experimental features for legacy tools on Windows.

• Non-determinism in build behavior depending on machine configuration. Note that building tools from source will now require additional dependencies instead of quietly proceeding with indeterminate results.

  For Ubuntu:

  libx11-dev libx11-xcb-dev libxcb-present-dev libxcb-dri3-dev wayland-protocols libva-dev libdrm-dev

  For CentOS/RedHat:

  libX11-devel libpciaccess-devel libXext-devel libXfixes-devel wayland-devel wayland-protocols-devel wayland-devel libdrm-devel libva libdrm-devel

oneVPL 2022.2.0 has been updated to include functional and security updates. Users should update to the latest version.

Issues and Limitations

• On Ubuntu 20.04, during basekit install you may see a warning about missing OpenCL support. You can verify the graphics stack components are correctly installed by running one of the interop samples with -hw. See https://github.com/oneapi-src/oneVPL for more information.
• CMake DOCDIR is not correctly configured when using custom prefix

C++/Python previews

• This is a preview release made available to gather feedback for API improvements. Compatibility with future releases is not guaranteed.

Dispatcher

• MFXInit() and MFXInitEx() functions have been deprecated in the 2.0 oneVPL Specification. Use MFXLoad() instead. See the transition guide for more details.
• If initialized with MFXInit() or MFXInitEx(), support is limited to the 1.x API and will load Intel(R) Media SDK hardware library rather than oneVPL hardware library.
• For legacy GPU hardware enabled by Intel(R) Media SDK, only API features up to 1.35 are available, even when initialized with MFXLoad. For more details, see Upgrading from Intel® Media SDK to Intel® oneAPI Video Processing Library.
• Dispatcher support has been extended to include hardware implementations, including those that implement API versions lower then 2.0. Applications patterned after the 2021.1.1 release samples, rather than the 2.0 specification may fail after re-build as the previous sample code made the assumption that 2.0 APIs would be available. To remedy this please follow the coding patterns in the oneVPL spec
• Sessions initialized with MFXVideoSession::InitEx() defined in file mfxvideo++.h are limited to using the following fields in structure mfxInitParam: Implementation, Version. Applications which require setting non-default values for the following fields must use the C function MFXInitEx() instead: ExternalThreads, GPUCopy, ExtParam, NumExtParam.

Tools and samples

• Releases installed before the 2.4 API update may cause cmake build failures on Linux* OS due to compatibility issues. Prior package versions were aligned with release versions rather than API. As a result, find_package looks for a current version (2.4) but finds a larger legacy version (2021.2.2) and assumes forward compatibility.
• sample_decode may not finish with multi-resolution input in external memory mode with CPU implementation.  
• legacy-vpp sample in hardware mode is not supported on Skylake systems.
• Encode B-frame distance setting is inconsistent between CPU and GPU implementations. For the CPU implementation 0 means no B-frames, while for the GPU implementation 1 means no B-frames.
• For CPU implementation, colorspace flags are required when using sample_* tools,. If colorspace is not set tools will fail. Note: CPU implementation default colorspaces are I420 and I010.
• The sample_multi_transcode tool included in this release is only intended for GPU operation to remain more closely aligned with the version of this tool released with Intel(R) Media SDK.
• The sample_multi_transcode tool has a synchronization issue in 1->N pipelines. When decode is faster than encoders, the issue can cause the free frames consumed faster than the framework released, eventually resulting in tool crash when there is no more memory available.
• hello-transcode sample only supports the oneVPL CPU implementation.
• Windows samples are installed to C:\Program Files (x86)\Intel\oneAPI\vpl\latest\examples by default. This should not be a writable location, so you will not be able to build samples here. To build examples, copy this folder to another location first.

v2022.1.0

Compare Source

New in this release

Added

• Updated oneVPL dispatcher to support API 2.6
• Added ONEVPL_PRIORITY_PATH for RT loading
• Extended multi-adapter to support most combinations of GPU hardware that works with Intel(R) Media SDK and oneVPL
• Updated documentation on working with multiple adapters using 2.x API
• Added support for extended device ID on legacy GPUs
• Added support for Intel® Arc™ A Series Graphics
• Added support for:
  • Rocky Linux*
  • Windows* 11
  • Windows* Server 2022
  • Microsoft Visual Studio* 2022

Changed

• Intel(R) Media SDK is loaded when DX9 is requested

Depreciated

• Support for Microsoft Visual Studio* 2017

Fixed

• MFXCloneSession is not functional on legacy GPU systems
• hello-encode not working on DG2 due to default input resolution

oneVPL 2022.1.0 has been updated to include functional and security updates. Users should update to the latest version.

Issues and Limitations

• On Ubuntu 20.04, during basekit install you may see a warning about missing OpenCL support. You can verify the graphics stack components are correctly installed by running one of the interop samples with -hw. See https://github.com/oneapi-src/oneVPL for more information.

C++/Python previews

• This is a preview release made available to gather feedback for API improvements. Compatibility with future releases is not guaranteed.

Dispatcher

• MFXInit() and MFXInitEx() functions have been deprecated in the 2.0 oneVPL Specification. Use MFXLoad() instead. See the transition guide for more details.
• If initialized with MFXInit() or MFXInitEx(), support is limited to the 1.x API and will load Intel(R) Media SDK hardware library rather than oneVPL hardware library.
• For legacy GPU hardware enabled by Intel(R) Media SDK, only API features up to 1.35 are available, even when initialized with MFXLoad. For more details, see Upgrading from Intel® Media SDK to Intel® oneAPI Video Processing Library.
• Dispatcher support has been extended to include hardware implementations, including those that implement API versions lower then 2.0. Applications patterned after the 2021.1.1 release samples, rather than the 2.0 specification may fail after re-build as the previous sample code made the assumption that 2.0 APIs would be available. To remedy this please follow the coding patterns in the oneVPL spec
• Sessions initialized with MFXVideoSession::InitEx() defined in file mfxvideo++.h are limited to using the following fields in structure mfxInitParam: Implementation, Version. Applications which require setting non-default values for the following fields must use the C function MFXInitEx() instead: ExternalThreads, GPUCopy, ExtParam, NumExtParam.

Tools and samples

• Releases installed before the 2.4 API update may cause cmake build failures on Linux* OS due to compatibility issues. Prior package versions were aligned with release versions rather than API. As a result, find_package looks for a current version (2.4) but finds a larger legacy version (2021.2.2) and assumes forward compatibility.
• sample_decode may not finish with multi-resolution input in external memory mode with CPU implementation.  
• legacy-vpp sample in hardware mode is not supported on Skylake systems.
• Encode B-frame distance setting is inconsistent between CPU and GPU implementations. For the CPU implementation 0 means no B-frames, while for the GPU implementation 1 means no B-frames.
• Colorspace flags are required when using sample_* tools, if colorspace is not set tools will fail.
• The sample_multi_transcode tool included in this release is only intended for GPU operation to remain more closely aligned with the version of this tool released with Intel(R) Media SDK.
• The sample_multi_transcode tool has a synchronization issue in 1->N pipelines. When decode is faster than encoders, the issue can cause the free frames consumed faster than the framework released, eventually resulting in tool crash when there is no more memory available.
• hello-transcode sample only supports the oneVPL CPU implementation.
• sample_decode may stop responding if input changes resolution.
• sample_encode software mode does not support NV12 as the input color format. Use i420 with the "i420" argument since NV12 is the default format.
• sample_encode does not support preprocess commands for scaling or color conversion for CPU
• Windows samples are installed to C:\Program Files (x86)\Intel\oneAPI\vpl\latest\examples by default. This should not be a writable location, so you will not be able to build samples here. To build examples, copy this folder to another location first.

v2022.0.0

Compare Source

New in This Release

• Updated mfxvideo++.h to remove deprecation warnings
• Sample* tools select oneVPL 2.x APIs by default
• Sample* tool update to support new GPU features
• Updates to C++ & Python previews:
  • AV1 extension buffer support
  • new property interface
  • Targets Python 3.7
• Updated documentation and build for OpenVINO interop sample
• The libmfx.dll and libmfx.so.2021.1.11 libraries, that had been renamed to libvpl.* have been removed

For more information on the preview C++/Python APIs and Samples, see
https://software.intel.com/content/www/us/en/develop/articles/onevpl-preview-examples.html

oneVPL 2022.0.0 has been updated to include functional and security updates. Users should update to the latest version.

Issues and Limitations

• On Ubuntu 20.04, during basekit install you may see a warning about missing OpenCL support. You can verify the graphics stack components are correctly installed by running one of the interop samples with -hw. See https://github.com/oneapi-src/oneVPL for more information.

C++/Python previews

• This is a preview release made available to gather feedback for API improvements. Compatibility with future releases is not guaranteed.

Dispatcher

• MFXCloneSession() is supported only for sessions created using MFXInit() or MFXInitEx(). To clone a session created using MFXCreateSession(), the application may call MFXCreateSession() a second time, followed by MFXJoinSession().
• In multi-adapter configurations with a mix of legacy and Xe GPUs, only the oneVPL implementation will be loaded. This means legacy MSDK device(s) cannot be used in this scenario. In this case oneVPL applications should target only the Xe device(s). If an application must target both, use Media SDK dispatcher and choose the default runtime to load with the INTEL_MEDIA_RUNTIME environment variable. See the Media SDK Readme for more information.
• MFXInit() and MFXInitEx() functions have been deprecated in the 2.0 oneVPL Specification. Use MFXLoad() instead. See the transition guide for more details.
• If initialized with MFXInit() or MFXInitEx(), support is limited to the 1.x API and will load Intel(R) Media SDK hardware library rather than oneVPL hardware library.
• If both Intel(R) Media SDK and oneVPL hardware libraries are installed, only oneVPL libraries will be loaded via MFXLoad(). See the oneVPL specification for more details.
• The Media SDK runtimes enabling legacy GPU hardware only provide API features up to 1.35, even when initialized with MFXLoad. For more details, see Upgrading from Intel® Media SDK to Intel® oneAPI Video Processing Library.
• Dispatcher support has been extended to include hardware implementations, including those that implement API versions lower then 2.0. Applications patterned after the 2021.1.1 release samples, rather than the 2.0 specification may fail after re-build as the previous sample code made the assumption that 2.0 APIs would be available. To remedy this please follow the coding patterns in the oneVPL spec

Tools and samples

• Releases installed prior to the 2.4 API update may cause CMAKE build failures on Linux due to compatibility issues. Prior package versions were aligned with release version, rather than API. As a result find_package will look for a current version i.e. 2.4 but find a larger legacy usage i.e. 2021.2.2 and assume forward compatibility.
• decvpp_tool currently only supports Linux operating systems
• decvpp_tool requires the graphics stack installed even when in CPU only mode.
• sample_decode may not finish with multi-resolution input in external memory mode with CPU runtime.
• legacy-vpp sample in hardware mode is not supported on Sky Lake.
• Encode B-frame distance setting is inconsistent between CPU and GPU implementations. For the CPU implementation 0 means no B-frames, while for the GPU implementation 1 means no B-frames.
• Colorspace flags are required when using sample_* tools, if colorspace is not set tools will fail.
• The sample_multi_transcode tool included in this release is only intended for GPU operation to remain more closely aligned with the version of this tool released with Intel(R) Media SDK.
• The sample_multi_transcode tool has a synchronization issue in 1->N pipelines. When decode is faster than encoders, the issue can cause the free frames consumed faster than the framework released, eventually resulting in tool crash when there is no more memory available.
• hello-transcode sample only supports the oneVPL CPU implementation in this release.
• sample_decode may stop responding if the input is switched between multiple resolutions.
• sample_encode software mode does not support NV12 as the input color format. Use i420 with the "i420" argument since NV12 is the default format.
• sample_encode occasionally hangs for (CPU) SVT-HEVC encodes when using VBR in Ubuntu 18.04.
• sample_encode does not support preprocess commands for scaling or color conversion.
• sample_encode, sample_decode, and sample_vpp are not in sync with Media SDK's version of these tools. This will be corrected in future releases.
• Windows samples are installed to C:\Program Files (x86)\Intel\oneAPI\vpl\latest\examples by default. This should not be a writable location, so you will not be able to build samples here. To build examples, copy this folder to another location first.

v2021.6.0

Compare Source

New in This Release

• Updated dispatcher to API 2.5
• Internal memory support added to dpcpp-blur sample

For more information on the preview C++/Python APIs and Samples, see
https://software.intel.com/content/www/us/en/develop/articles/onevpl-preview-examples.html

oneVPL 2021.6.0 has been updated to include functional and security updates. Users should update to the latest version.

Issues and Limitations

• On Ubuntu 20.04, during basekit install you may see a warning about missing OpenCL support. You can verify the graphics stack components are correctly installed by running one of the interop samples with -hw. See https://github.com/oneapi-src/oneVPL for more information.

C++/Python previews

• This is a preview release made available to gather feedback for API improvements. Compatibility with future releases is not guaranteed.

Dispatcher

• In multi-adapter configurations with a mix of legacy and Xe GPUs, only the oneVPL implementation will be loaded. This means legacy MSDK device(s) cannot be used in this scenario. In this case oneVPL applications should target only the Xe device(s). If an application must target both, use Media SDK dispatcher and choose the default runtime to load with the INTEL_MEDIA_RUNTIME environment variable. See the Media SDK Readme for more information.
• Builds of oneVPL from source assume single configuration generators on Linux and multi configuration generators on Windows.
• MFXInit() and MFXInitEx() functions have been deprecated in the 2.0 oneVPL Specification. Use MFXLoad() instead. See the transition guide for more details.
• If initialized with MFXInit() or MFXInitEx(), support is limited to the 1.x API and will load Intel(R) Media SDK hardware library rather than oneVPL hardware library.
• If both Intel(R) Media SDK and oneVPL hardware libraries are installed, only oneVPL libraries will be loaded via MFXLoad(). See the oneVPL specification for more details.
• The Media SDK runtimes enabling legacy GPU hardware only provide API features up to 1.35, even when initialized with MFXLoad. For more details, see Upgrading from Intel® Media SDK to Intel® oneAPI Video Processing Library.
• The libmfx.dll and libmfx.so.2021.1.11 dispatchers are deprecated. They are provided for backwards compatibility only and will be removed from a future release. They do not include any changes since the 2021.1.1 release.
• Dispatcher support has been extended to include hardware implementations, including those that implement API versions lower then 2.0. Applications patterned after the 2021.1.1 release samples, rather than the 2.0 specification may fail after re-build as the previous sample code made the assumption that 2.0 APIs would be available. To remedy this please follow the coding patterns in the oneVPL spec

Tools and samples

• Releases installed prior to the 2.4 API update may cause CMAKE build failures on Linux due to compatibility issues. Prior package versions were aligned with release version, rather than API. As a result find_package will look for a current version i.e. 2.4 but find a larger legacy usage i.e. 2021.2.2 and assume forward compatibility.
• decvpp_tool requires the graphics stack installed even when in CPU only mode.
• sample_decode may not finish with multi-resolution input in external memory mode with CPU runtime.
• sample_encode does not work in case of enabled VPP and internal memory allocator.
• legacy-vpp sample in hardware mode is not supported on Sky Lake.
• decvpp_tool does not support gen12 platforms on Windows in Hardware mode.
• Encode B-frame distance setting is inconsistent between CPU and GPU implementations. For the CPU implementation 0 means no B-frames, while for the GPU implementation 1 means no B-frames.
• Colorspace flags are required when using sample_* tools, if colorspace is not set tools will fail.
• The sample_multi_transcode tool included in this release is only intended for GPU operation to remain more closely aligned with the version of this tool released with Intel(R) Media SDK.
• The sample_multi_transcode tool has a synchronization issue in 1->N pipelines. When decode is faster than encoders, the issue can cause the free frames consumed faster than the framework released, eventually resulting in tool crash when there is no more memory available.
• hello-transcode sample only supports the oneVPL CPU implementation in this release.
• sample_decode may stop responding if the input is switched between multiple resolutions.
• sample_encode software mode does not support NV12 as the input color format. Use i420 with the "i420" argument since NV12 is the default format.
• sample_encode occasionally hangs for (CPU) SVT-HEVC encodes when using VBR in Ubuntu 18.04.
• sample_encode does not support preprocess commands for scaling or color conversion.
• sample_encode, sample_decode, and sample_vpp are not in sync with Media SDK's version of these tools. This will be corrected in future releases.
• Windows samples are installed to C:\Program Files (x86)\Intel\oneAPI\vpl\latest\examples by default. This should not be a writable location, so you will not be able to build samples here. To build examples, copy this folder to another location first.

v2021.5.0

Compare Source

New in This Release

• Added option to build dispatcher as a static library
• Added ability to build dispatcher under MinGW
• Fixes for tools and samples

For more information on the preview C++/Python APIs and Samples, see
https://software.intel.com/content/www/us/en/develop/articles/onevpl-preview-examples.html

Issues and Limitations

C++/Python previews

• This is a preview release made available to gather feedback for API improvements. Compatibility with future releases is not guaranteed.

Dispatcher

• MFXInit() and MFXInitEx() functions have been deprecated in the 2.0 oneVPL Specification. Use MFXLoad() instead. See the transition guide for more details.
• If initialized with MFXInit() or MFXInitEx(), support is limited to the 1.x API and will load Intel(R) Media SDK hardware library rather than oneVPL hardware library.
• If both Intel(R) Media SDK and oneVPL hardware libraries are installed, only oneVPL libraries will be loaded via MFXLoad(). See the oneVPL specification for more details.
• The Media SDK runtimes enabling legacy GPU hardware only provide API features up to 1.35, even when initialized with MFXLoad. For more details, see Upgrading from Intel® Media SDK to Intel® oneAPI Video Processing Library.
• The libmfx.dll and libmfx.so.2021.1.11 dispatchers are deprecated. They are provided for backwards compatibility only and will be removed from a future release. They do not include any changes since the 2021.1.1 release.
• Dispatcher support has been extended to include hardware implementations, including those that implement API versions lower then 2.0. Applications patterned after the 2021.1.1 release samples, rather than the 2.0 specification may fail after re-build as the previous sample code made the assumption that 2.0 APIs would be available. To remedy this please follow the coding patterns in the oneVPL spec

Tools and samples

• Releases installed prior to the 2.4 API update may cause CMAKE build failures on Linux due to compatibility issues. Prior package versions were aligned with release version, rather than API. As a result find_package will look for a current version i.e. 2.4 but find a larger legacy usage i.e. 2021.2.2 and assume forward compatibility.
• dpccp-blur sample incorrectly states its usage. The sample example commandline should read:

dpcpp-blur -i in.i420 -w 128 -h 96
To view: ffplay -f rawvideo -pixel_format bgra -video_size 256x192 -pixel_format yuv420p out.raw

• legacy-vpp sample in hardware mode is not supported on Sky Lake.
• hello-transcode readme incorrectly implies sample runs on hardware.
• decvpp_tool does not support gen12 platforms on Windows in Hardware mode.
• Encode B-frame distance setting is inconsistent between CPU and GPU implementations. For the CPU implementation 0 means no B-frames, while for the GPU implementation 1 means no B-frames.
• Colorspace flags are required when using sample_* tools, if colorspace is not set tools will fail.
• Input size should be aligned to 16 bytes for sample_encode.
• The sample_multi_transcode tool included in this release is only intended for GPU operation to remain more closely aligned with the version of this tool released with Intel(R) Media SDK.
• The sample_multi_transcode tool has a synchronization issue in 1->N pipelines. When decode is faster than encoders, the issue can cause the free frames consumed faster than the framework released, eventually resulting in tool crash when there is no more memory available.
• hello-transcode sample only supports the oneVPL CPU implementation in this release.
• sample_decode may stop responding if the input is switched between multiple resolutions.
• sample_encode occasionally hangs for (CPU) SVT-HEVC encodes when using VBR in Ubuntu 18.04.
• sample_encode does not work if the input is scaled or color converted.
• sample_encode, sample_decode, and sample_vpp are not in sync with Media SDK's version of these tools. This will be corrected in future releases.
• Windows samples are installed to C:\Program Files (x86)\Intel\oneAPI\vpl\latest\examples by default. This should not be a writable location, so you will not be able to build samples here. To build examples, copy this folder to another location first.
• When configuring systems to run the OpenVINO interop samples in Linux gmmlib version conflicts can occur. Debug shows undefined GmmLib symbols as the cause of a runtime error. This can be mitigated by using the media stack integrated with OpenVINO installation. Uninstall other versions of libva, iHD, and libgmm then select Media SDK when installing OpenVINO as described in the OpenVINO install documentation.

v2021.4.0

Compare Source

New in This Release

• Updated dispatcher API to 2.4
• Advanced OpenVINO interop sample w/ remoteBlob support (Linux only)
• C++ API and Samples (Preview)
• Python API and Samples (Preview)
• Added logging capability to Dispatcher
• Added new tools: sample_multi_transcode and decvpp_tool
• Added debug libraries to Windows package

For more information on the preview C++/Python APIs and Samples, see
https://software.intel.com/content/www/us/en/develop/articles/onevpl-preview-examples.html

Issues and Limitations

C++/Python previews

• This is a preview release made available to gather feedback for API
  improvements. Compatibility with future releases is not guaranteed.

Dispatcher

• MFXInit() and MFXInitEx() functions have been deprecated in the 2.0
  oneVPL Specification. Use MFXLoad() instead. See the transition
  guide for more details.
• If initialized with MFXInit() or MFXInitEx(), support is limited to
  the 1.x API and will load Intel(R) Media SDK hardware library rather
  than oneVPL hardware library.
• If both Intel(R) Media SDK and oneVPL hardware libraries are
  installed, only oneVPL libraries will be loaded via MFXLoad(). See the
  oneVPL specification for more details.
• The Media SDK runtimes enabling legacy GPU hardware only provide API
  features up to 1.35, even when initialized with MFXLoad. For more
  details, see Upgrading from Intel® Media SDK to Intel® oneAPI Video
  Processing
  Library.
• The libmfx.dll and libmfx.so.2021.1.11 dispatchers are
  deprecated. They are provided for backwards compatibility only and
  will be removed from a future release. They do not include any
  changes since the 2021.1.1 release.
• Dispatcher support has been extended to include hardware
  implementations, including those that implement API versions lower
  then 2.0. Applications patterned after the 2021.1.1 release samples,
  rather than the 2.0 specification may fail after re-build as the
  previous sample code made the assumption that 2.0 APIs would be
  available. To remedy this please follow the coding patterns in the
  oneVPL
  spec

Tools and samples

• Encode B-frame distance setting is inconsistent between CPU and GPU
  implementations. For the CPU implementation 0 means no B-frames, while
  for the GPU implementation 1 means no B-frames.
• Colorspace flags are required when using sample_* tools, if colorspace
  is not set tools will fail.
• Input size should be aligned to 16 bytes for sample_encode.
• The sample_multi_transcode tool included in this release is only
  intended for GPU operation to remain more closely aligned with the
  version of this tool released with Intel(R) Media SDK.
• The sample_multi_transcode tool has a synchronization issue in 1->N
  pipelines. When decode is faster than encoders, the issue can cause
  the free frames consumed faster than the framework released,
  eventually resulting in tool crash when there is no more memory
  available.
• hello-transcode sample only supports the oneVPL CPU implementation in
  this release.
• sample_decode may stop responding if the input is switched between
  multiple resolutions.
• sample_encode occasionally hangs for (CPU) SVT-HEVC encodes when using
  VBR in Ubuntu 18.04.
• sample_encode does not work if the input is scaled or color converted.
• sample_encode, sample_decode, and sample_vpp are not in sync with
  Media SDK's version of these tools. This will be corrected in future
  releases.
• Windows samples are installed to C:\Program
  Files (x86)\Intel\oneAPI\vpl\latest\examples by default. This should
  not be a writable location, so you will not be able to build samples
  here. To build examples, copy this folder to another location first.
• When configuring systems to run the OpenVINO interop samples in Linux
  gmmlib version conflicts can occur. Debug shows undefined GmmLib
  symbols as the cause of a runtime error. This can be mitigated by
  using the media stack integrated with OpenVINO installation.
  Uninstall other versions of libva, iHD, and libgmm then select Media
  SDK when installing OpenVINO as described in the OpenVINO install
  documentation.

CPU implementation

• Decode input bitstream buffer size must be large enough to hold
  several frames. Buffer sizes that are too small may cause issues. The
  necessary minimum size is stream dependent but enough for 10 frames is
  a conservative estimate.
• AVC/H.264 encode is disabled due to licensing restrictions. To enable
  it, refer to the instructions to Optionally enable H.264
  encode.
• A subset of parameters and functions from the specification are
  implemented. For more information on mandatory and optional APIs and
  features, see the oneVPL
  specification.
• For the Windows* release, Visual C++* Redistributable for Visual
  Studio* 2015 or higher is required. Without this, an error reporting
  a missing MSVCP140.dll will be generated.
• MFX_BITSTREAM_EOS from the input bitstream dataFlag is ignored by
  MFXVideoDECODE_DecodeFrameAsync().

v2021.2.2

Compare Source

This release is focused on alignment with the 2.2 oneVPL specification, enabling GPU support, and delivering feature support for partners and customers.

The Intel® oneAPI Video Processing Library (oneVPL) lets developers add high- speed, real-time decoding, encoding, and video processes to their applications. Its single video API provides direct access to advanced Intel® CPU instructions and gives you total control of video processing needs.

This release delivers the following new features:
• Dispatcher and CPU implementation updated to align with oneVPL Specification 2.2
• Legacy Intel(R) Media SDK test tools (with CPU and GPU support)
• Intel(R) Media SDK to oneVPL migration guide
• pkg-config support
• Windows* 32-bit support
• Legacy mfxvideo++ header
• New Preview Sample:
-- oneVPL-OpenVINO Interop Sample (Preview) (source code only)
• New OS support:
-- Ubuntu 20.10

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.