v2023.2.0

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

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 Intel® Distribution of 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

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
  Intel® Distribution of 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

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

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

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 Intel® Distribution of 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

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

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 Intel® Distribution of 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

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

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.