.rst .pdf

open issue suggest edit

Contents

oneVPL Session

Before calling any oneVPL functions, the application must initialize the library and create a oneVPL session. A oneVPL session maintains context for the use of any of DECODE, ENCODE, VPP, DECODE_VPP functions.

Intel^® Media Software Development Kit Dispatcher (Legacy)

The MFXInit() or MFXInitEx() function starts (initializes) a session. The MFXClose() function closes (de-initializes) the session. To avoid memory leaks, always call MFXClose() after MFXInit().

Important

MFXInit() and MFXInitEx() are deprecated starting from API 2.0. Applications must use MFXLoad() and MFXCreateSession() to initialize implementations.

Important

For backward compatibility with existent Intel^® Media Software Development Kit applications oneVPL session can be created and initialized by the legacy dispacther through MFXInit() or MFXInitEx() calls.

The application can initialize a session as a software-based session (MFX_IMPL_SOFTWARE) or a hardware-based session (MFX_IMPL_HARDWARE). In a software-based session, the SDK functions execute on a CPU. In a hardware-base session, the SDK functions use platform acceleration capabilities. For platforms that expose multiple graphic devices, the application can initialize a session on any alternative graphic device using the MFX_IMPL_HARDWARE, MFX_IMPL_HARDWARE2, MFX_IMPL_HARDWARE3, or MFX_IMPL_HARDWARE4 values of mfxIMPL.

The application can also initialize a session to be automatic ( MFX_IMPL_AUTO or MFX_IMPL_AUTO_ANY), instructing the dispatcher library to detect the platform capabilities and choose the best SDK library available. After initialization, the SDK returns the actual implementation through the MFXQueryIMPL() function.

Internally, the dispatcher works as follows:

1. Dispatcher searches for the shared library with the specific name:

   OS	Name	Description
   Linux*	libmfxsw64.so.1	64-bit software-based implementation
   Linux	libmfxsw32.so.1	32-bit software-based implementation
   Linux	libmfxhw64.so.1	64-bit hardware-based implementation
   Linux	libmfxhw64.so.1	32-bit hardware-based implementation
   Windows*	libmfxsw32.dll	64-bit software-based implementation
   Windows	libmfxsw32.dll	32-bit software-based implementation
   Windows	libmfxhw64.dll	64-bit hardware-based implementation
   Windows	libmfxhw64.dll	32-bit hardware-based implementation

2. Once the library is loaded, the dispatcher obtains addresses for each SDK function. See the Exported Functions/API Version table for the list of functions to expose.

How the shared library is identified using the implementation search strategy will vary according to the OS.

• On Windows, the dispatcher searches the following locations, in the specified order, to find the correct implementation library:

  1. The Driver Store directory for the current adapter. All types of graphics drivers can install libraries in this directory. Learn more about Driver Store.

  2. The directory specified for the current hardware under the registry key HKEY_CURRENT_USER\Software\Intel\MediaSDK\Dispatch.

  3. The directory specified for the current hardware under the registry key HKEY_LOCAL_MACHINE\Software\Intel\MediaSDK\Dispatch.

  4. The directory that is stored in these registry keys: C:Program FilesIntelMedia SDK. This directory is where legacy graphics drivers install libraries.

  5. The directory where the current module (the module that links the dispatcher) is located (only if the current module is a dll).

  After the dispatcher completes the main search, it additionally checks:

  1. The directory of the exe file of the current process, where it looks for software implementation only, regardless of which implementation the application requested.

  2. Default dll search. This provides loading from the directory of the application’s exe file and from the System32 and SysWOW64 directories. Learn more about default dll search order.

  3. The System32 and SysWOW64 directories, which is where DCH graphics drivers install libraries.

• On Linux, the dispatcher searches the following locations, in the specified order, to find the correct implementation library:

  1. Directories provided by the environment variable LD_LIBRARY_PATH.

  2. Content of the /etc/ld.so.cache cache file.

  3. Default path /lib, then /usr/lib or /lib64, and then /usr/lib64 on some 64 bit OSs. On Debian: /usr/lib/x86_64-linux-gnu.

  4. SDK installation folder.

oneVPL Dispatcher

The oneVPL dispatcher extends the legacy dispatcher by providing additional ability to select the appropriate implementation based on the implementation capabilities. Implementation capabilities include information about supported decoders, encoders, and VPP filters. For each supported encoder, decoder, and filter, capabilities include information about supported memory types, color formats, and image (frame) size in pixels.

The recommended approach to configure the dispatcher’s capabilities search filters and to create a session based on a suitable implementation is as follows:

1. Create loader with MFXLoad().

2. Create loader’s configuration with MFXCreateConfig().

3. Add configuration properties with MFXSetConfigFilterProperty().

4. Explore available implementations with MFXEnumImplementations().

5. Create a suitable session with MFXCreateSession().

The procedure to terminate an application is as follows:

1. Destroy session with MFXClose().

2. Destroy loader with MFXUnload().

Note

Multiple loader instances can be created.

Note

Each loader may have multiple configuration objects associated with it. When a configuration object is modified through MFXSetConfigFilterProperty() it implicitly impacts the state and configuration of the associated loader.

Important

One configuration object can handle only one filter property.

Note

Multiple sessions can be created by using one loader object.

When the dispatcher searches for the implementation, it uses the following priority rules:

1. Hardware implementation has priority over software implementation.

2. General hardware implementation has priority over VSI hardware implementation.

3. Highest API version has higher priority over lower API version.

Note

Implementation has priority over the API version. In other words, the dispatcher must return the implementation with the highest API priority (greater than or equal to the implementation requested).

How the shared library is identified using the implementation search strategy will vary according to the OS.

• On Windows, the dispatcher searches the following locations, in the specified order, to find the correct implementation library:

  1. The Driver Store directory for all available adapters. All types of graphics drivers can install libraries in this directory. Learn more about Driver Store. Applicable only for Intel implementations.

  2. The directory of the exe file of the current process.

  3. Current working directory.

  4. PATH enviromental variable.

  5. For backward compatibility with older spec versions, dispatcher also checks user-defined search folders which are provided by ONEVPL_SEARCH_PATH enviromental variable.

• On Linux, the dispatcher searches the following locations, in the specified order, to find the correct implementation library:

  1. Directories provided by the environment variable LD_LIBRARY_PATH.

  2. Default path /lib, then /usr/lib or /lib64, and then /usr/lib64 on some 64 bit OSs. On Debian: /usr/lib/x86_64-linux-gnu.

  3. Current working directory.

  4. For backward compatibility with older spec versions, dispatcher also checks user-defined search folders which are provided by ONEVPL_SEARCH_PATH enviromental variable.

When oneVPL dispatcher searchers for the legacy Intel^® Media Software Development Kit implementation it uses legacy dispatcher search order.

The dispatcher supports different software implementations. The user can use the mfxImplDescription::VendorID field, the mfxImplDescription::VendorImplID field, or the mfxImplDescription::ImplName field to search for the specific implementation.

Internally, the dispatcher works as follows:

1. Dispatcher loads any shared library with libvpl* prefix in the library name in the given search folders.

2. For each loaded library, the dispatcher tries to resolve address of the MFXQueryImplsDescription() function to collect the implementation’s capabilities.

3. Once the user has requested to create the session based on this implementation, the dispatcher obtains addresses of each oneVPL function. See the Exported Functions/API Version table for the list of functions to export.

Note

For backward compatibility with Intel^® Media Software Development Kit, the dispatcher will first try to load Intel^® Media Software Development Kit if API version 1.x was requested. If loading fails, the dispatcher will search for the implementation with highest 2.x API version and load that version.

oneVPL Dispatcher Configuration Properties

The Dispatcher Configuration Properties Table shows property strings supported by the dispatcher. Table organized in the hierarchy way, to create the string, go from the left to right from column to column and concatenate strings by using . (dot) as the separator.

Dispatcher Configuration Properties

Structure name	Property	Value Data Type	Comment
mfxImplDescription	mfxImplDescription .Impl	MFX_VARIANT_TYPE_U32
	mfxImplDescription .AccelerationMode	MFX_VARIANT_TYPE_U32	The mode will be used for session initilization
	mfxImplDescription .ApiVersion .Version	MFX_VARIANT_TYPE_U32
	mfxImplDescription .ApiVersion .Major	MFX_VARIANT_TYPE_U16
	mfxImplDescription .ApiVersion .Minor	MFX_VARIANT_TYPE_U16
	mfxImplDescription .ImplName	MFX_VARIANT_TYPE_PTR	Pointer to the null-terminated string.
	mfxImplDescription .License	MFX_VARIANT_TYPE_PTR	Pointer to the null-terminated string.
	mfxImplDescription .Keywords	MFX_VARIANT_TYPE_PTR	Pointer to the null-terminated string.
	mfxImplDescription .VendorID	MFX_VARIANT_TYPE_U32
	mfxImplDescription .VendorImplID	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxSurfacePoolMode	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxDeviceDescription .device .DeviceID	MFX_VARIANT_TYPE_PTR	Pointer to the null-terminated string.
	mfxImplDescription .mfxDecoderDescription .decoder .CodecID	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxDecoderDescription .decoder .MaxcodecLevel	MFX_VARIANT_TYPE_U16
	mfxImplDescription .mfxDecoderDescription .decoder .decprofile .Profile	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxDecoderDescription .decoder .decprofile .Profile .decmemdesc .MemHandleType	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxDecoderDescription .decoder .decprofile .Profile .decmemdesc .Width	MFX_VARIANT_TYPE_PTR	Pointer to the mfxRange32U object
	mfxImplDescription .mfxDecoderDescription .decoder .decprofile .Profile .decmemdesc .Height	MFX_VARIANT_TYPE_PTR	Pointer to the mfxRange32U object
	mfxImplDescription .mfxDecoderDescription .decoder .decprofile .Profile .decmemdesc .ColorFormats	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxEncoderDescription .encoder .CodecID	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxEncoderDescription .encoder .MaxcodecLevel	MFX_VARIANT_TYPE_U16
	mfxImplDescription .mfxEncoderDescription .encoder .BiDirectionalPrediction	MFX_VARIANT_TYPE_U16
	mfxImplDescription .mfxEncoderDescription .encoder .encprofile .Profile	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxEncoderDescription .encoder .encprofile .Profile .encmemdesc .MemHandleType	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxEncoderDescription .encoder .encprofile .Profile .encmemdesc .Width	MFX_VARIANT_TYPE_PTR	Pointer to the mfxRange32U object
	mfxImplDescription .mfxEncoderDescription .encoder .encprofile .Profile .encmemdesc .Height	MFX_VARIANT_TYPE_PTR	Pointer to the mfxRange32U object
	mfxImplDescription .mfxEncoderDescription .encoder .encprofile .Profile .encmemdesc .ColorFormats	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxVPPDescription .filter .FilterFourCC	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxVPPDescription .filter .MaxDelayInFrames	MFX_VARIANT_TYPE_U16
	mfxImplDescription .mfxVPPDescription .filter .memdesc .MemHandleType	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxVPPDescription .filter .memdesc .Width	MFX_VARIANT_TYPE_PTR	Pointer to the mfxRange32U object
	mfxImplDescription .mfxVPPDescription .filter .memdesc .Height	MFX_VARIANT_TYPE_PTR	Pointer to the mfxRange32U object
	mfxImplDescription .mfxVPPDescription .filter .memdesc .format .InFormat	MFX_VARIANT_TYPE_U32
	mfxImplDescription .mfxVPPDescription .filter .memdesc .format .OutFormats	MFX_VARIANT_TYPE_U32
mfxImplementedFunctions	mfxImplementedFunctions .FunctionsName	MFX_VARIANT_TYPE_PTR	Pointer to the buffer with string
N/A	DXGIAdapterIndex	MFX_VARIANT_TYPE_U32	Adapter index according to IDXGIFactory::EnumAdapters

Important

DXGIAdapterNum property is available for Windows only and filters only hardware implementations.

Examples of the property name strings:

• mfxImplDescription.mfxDecoderDescription.decoder.decprofile.Profile

• mfxImplDescription.mfxDecoderDescription.decoder.decprofile.decmemdesc.MemHandleType

• mfxImplementedFunctions.FunctionsName

Following properties are supported in a special manner: they are used to send additional data to the implementation through the dispatcher. Application needs to use MFXSetConfigFilterProperty() to set them up but they don’t influence on the implementation selection. They are used during the MFXCreateSession() function call to fine tune the implementation.

Dispatcher’s Special Properties

Property	Value data type
mfxHandleType	mfxVariantType::MFX_VARIANT_TYPE_U32
mfxHDL	mfxVariantType::MFX_VARIANT_TYPE_PTR

oneVPL Dispatcher Interactions

This sequence diagram visualize how application communcates with implementations via the dispacher.

Dispatcher API

This API is implemented in the dispatcher.

Implementation API

This API is provided by the any implementation.

The oneVPL dispacther is capable to load and initialize Intel^® Media Software Development Kit legacy library. The sequence diagram below demonstrates the approach.

Important

The dispacther doesn’t filter and report mfxDeviceDescription, mfxDecoderDescription, mfxEncoderDescription, mfxVPPDescription when enumerates or creates Intel^® Media Software Development Kit implementation. Once Intel^® Media Software Development Kit is loaded applications have to use legacy approach to query capabilities.

oneVPL Dispatcher Debug Log

The debug output of the dispatcher is controlled with the ONEVPL_DISPATCHER_LOG environment variable. To enable log output, set the ONEVPL_DISPATCHER_LOG environment variable value equals to “ON”.

By default, oneVPL dispatcher prints all log messages to the console. To redirect log output to the desired file, set the ONEVPL_DISPATCHER_LOG_FILE environmental variable with the file name of the log file.

Examples of Dispathcer’s Usage

This code illustrates simple usage of dispathcer to load first available library:

mfxLoader loader = MFXLoad();
MFXCreateSession(loader,0,&session);

This code illustrates simple usage of dispathcer to load first available HW accelerated library:

mfxLoader loader = MFXLoad();
mfxConfig cfg = MFXCreateConfig(loader);
mfxVariant ImplValue;
ImplValue.Type = MFX_VARIANT_TYPE_U32;
ImplValue.Data.U32 = MFX_IMPL_TYPE_HARDWARE;
MFXSetConfigFilterProperty(cfg,(const mfxU8 *)"mfxImplDescription.Impl",ImplValue);
MFXCreateSession(loader,0,&session);

This code illustrates how multiple sessions from multiple loaders can be created:

// Create session with software based implementation
mfxLoader loader1 = MFXLoad();
mfxConfig cfg1 = MFXCreateConfig(loader1);
mfxVariant ImplValueSW;
ImplValueSW.Type = MFX_VARIANT_TYPE_U32;
ImplValueSW.Data.U32 = MFX_IMPL_TYPE_SOFTWARE;
MFXSetConfigFilterProperty(cfg1,(const mfxU8 *)"mfxImplDescription.Impl",ImplValueSW);
MFXCreateSession(loader1,0,&sessionSW);

// Create session with hardware based implementation
mfxLoader loader2 = MFXLoad();
mfxConfig cfg2 = MFXCreateConfig(loader2);
mfxVariant ImplValueHW;
ImplValueHW.Type = MFX_VARIANT_TYPE_U32;
ImplValueHW.Data.U32 = MFX_IMPL_TYPE_HARDWARE;
MFXSetConfigFilterProperty(cfg2,(const mfxU8 *)"mfxImplDescription.Impl",ImplValueHW);
MFXCreateSession(loader2,0,&sessionHW);

// use both sessionSW and sessionHW
// ...
// Close everything
MFXClose(sessionSW);
MFXClose(sessionHW);
MFXUnload(loader1); // cfg1 will be destroyed here.
MFXUnload(loader2); // cfg2 will be destroyed here.

This code illustrates how multiple decoders from single loader can be created:

mfxLoader loader = MFXLoad();

// We want to have AVC decoder supported.
mfxConfig cfg1 = MFXCreateConfig(loader);
mfxVariant ImplValue;
ImplValue.Type = MFX_VARIANT_TYPE_U32;
ImplValue.Data.U32 = MFX_CODEC_AVC;
MFXSetConfigFilterProperty(cfg1,
            (const mfxU8 *)"mfxImplDescription.mfxDecoderDescription.decoder.CodecID",ImplValue);

// And we want to have HEVC encoder supported by the same implementation.
mfxConfig cfg2 = MFXCreateConfig(loader);
ImplValue.Type = MFX_VARIANT_TYPE_U32;
ImplValue.Data.U32 = MFX_CODEC_HEVC;
MFXSetConfigFilterProperty(cfg2,
            (const mfxU8 *)"mfxImplDescription.mfxEncoderDescription.encoder.CodecID",ImplValue);

// To create single session with both capabilities.
MFXCreateSession(loader,0,&session);

How To Check If Function is Implemented

There are two ways to check if particular function is implemented or not by the implementation.

This code illustrates how application can iterate through the whole list of implemented functions:

mfxHDL h;
// request pointer to the list. Assume that implementation supports that.
// Assume that `loader` is configured before.
mfxStatus sts = MFXEnumImplementations(loader, idx, MFX_IMPLCAPS_IMPLEMENTEDFUNCTIONS, &h);
// break if no idx
if (sts != MFX_ERR_NOT_FOUND) {
  // Cast typeless handle to structure pointer
  mfxImplementedFunctions *implemented_functions = (mfxImplementedFunctions*)h;

  // print out list of functions' name
  std::for_each(implemented_functions->FunctionsName, implemented_functions->FunctionsName +
                                                      implemented_functions->NumFunctions,
          [](mfxChar*  functionName) {
              std::cout << functionName << " is implemented" << std::endl;
          });
  // Release resource
  MFXDispReleaseImplDescription(loader, h);
}

This code illustrates how application can check that specific functions are implemented:

mfxSession session_handle;
loader = mfxLoader();

// We want to search for the implementation with Decode+VPP domain functions support.
// i.e we search for the MFXVideoDECODE_VPP_Init and MFXVideoDECODE_VPP_DecodeFrameAsync
// implemented functions
mfxConfig init_funct_prop = MFXCreateConfig(loader);
mfxVariant value;

// Filter property for the Init function
value.Type = mfxVariantType::MFX_VARIANT_TYPE_PTR;
value.Data.Ptr = (mfxHDL)"MFXVideoDECODE_VPP_Init";
MFXSetConfigFilterProperty(init_funct_prop, (const mfxU8*)"mfxImplementedFunctions.FunctionsName",
                           value);

// Filter property for the Process function
mfxConfig process_func_prop = MFXCreateConfig(loader);
value.Data.Ptr = (mfxHDL)"MFXVideoDECODE_VPP_DecodeFrameAsync";
MFXSetConfigFilterProperty(process_func_prop, (const mfxU8*)"mfxImplementedFunctions.FunctionsName",
                           value);

// create session from first matched implementation
MFXCreateSession(loader, 0, &session_handle);

How To Search For The Available encoder/decoder implementation

The CodecFormatFourCC enum specifies codec’s FourCC values. Application needs to assign this value to the field of mfxDecoderDescription::decoder::CodecID to search for the decoder or mfxEncoderDescription::encoder::CodecID to search for the encoder.

This code illustrates decoder’s implementation search procedure:

mfxSession hevc_session_handle;
loader = mfxLoader();

// We want to search for the HEVC decoder implementation
mfxConfig hevc_decoder_config = MFXCreateConfig(loader);
mfxVariant value;

// Filter property for the implementations with HEVC decoder
value.Type     = MFX_VARIANT_TYPE_U32;
value.Data.U32 = MFX_CODEC_HEVC;

MFXSetConfigFilterProperty(hevc_decoder_config
      , (const mfxU8*)"mfxImplDescription.mfxDecoderDescription.decoder.CodecID"
      , value);

// create session from first matched implementation
MFXCreateSession(loader, 0, &hevc_session_handle);

How To Search For The Available VPP Filter implementation

Each VPP filter identified by the filter ID. Filter ID is defined by corresponding to the filter extension buffer ID value which is defined in a form of fourCC value. Filter ID values are subset of the general ExtendedBufferID enum. The table references available IDs of VPP filters to search. Application needs to assign this value to the field of mfxVPPDescription::filter::FilterFourCC to search for the needed VPP filter.

VPP Filters ID

Filter ID	Description
MFX_EXTBUFF_VPP_DENOISE	Denoise filter (deprecated in 2.2)
MFX_EXTBUFF_VPP_DENOISE2	Denoise filter
MFX_EXTBUFF_VPP_MCTF	Motion-Compensated Temporal Filter (MCTF).
MFX_EXTBUFF_VPP_DETAIL	Detail/edge enhancement filter.
MFX_EXTBUFF_VPP_FRAME_RATE_CONVERSION	Frame rate conversion filter
MFX_EXTBUFF_VPP_IMAGE_STABILIZATION	Image stabilization filter
MFX_EXTBUFF_VPP_PROCAMP	ProcAmp filter
MFX_EXTBUFF_VPP_FIELD_PROCESSING	Field processing filter
MFX_EXTBUFF_VPP_COLOR_CONVERSION	Color Conversion filter
MFX_EXTBUFF_VPP_SCALING	Resize filter
MFX_EXTBUFF_VPP_COMPOSITE	Surfaces composition filter
MFX_EXTBUFF_VPP_DEINTERLACING	Deinterlace filter
MFX_EXTBUFF_VPP_ROTATION	Rotation filter
MFX_EXTBUFF_VPP_MIRRORING	Mirror filter
MFX_EXTBUFF_VPP_COLORFILL	ColorFill filter

This code illustrates VPP mirror filter implementation search procedure:

mfxSession mirror_session_handle;
loader = mfxLoader();

// We want to search for the VPP mirror implementation
mfxConfig  mirror_flt_config = MFXCreateConfig(loader);
mfxVariant value;

// Filter property for the implementations with VPP mirror
value.Type     = MFX_VARIANT_TYPE_U32;
value.Data.U32 = MFX_EXTBUFF_VPP_MIRRORING;

MFXSetConfigFilterProperty(mirror_flt_config
      , (const mfxU8*)"mfxImplDescription.mfxVPPDescription.filter.FilterFourCC"
      , value);

// create session from first matched implementation
MFXCreateSession(loader, 0, &mirror_session_handle);

How To Get Path to the Shared Library With the Implementation

Sessions can be created from different implementations, each implementations can be located in different shared libraries. To get path of the shared library with the implementation from which session can be or was created, application can use MFXEnumImplementations() and pass MFX_IMPLCAPS_IMPLPATH value as the outpt data request.

This code illustrates collection and print out path of implementations’s shared library:

mfxHDL h;
mfxSession def_session;

loader = mfxLoader();

// Create session from the first avialable implementation.
// That's why we no any filters need to be set.
// First avialable implementation has index equal to the 0.
MFXCreateSession(loader, 0, &def_session);

// Get and print out OS path to the loaded shared library
// with the implementation. It is absolutely OK to call
// MFXEnumImplementations after session creation just need to make
// sure that the same index of implementation is provided to the
// function call.
MFXEnumImplementations(loader, 0, MFX_IMPLCAPS_IMPLPATH, &h);
mfxChar* path = reinterpret_cast<mfxChar*>(h);

// Print out the path
std::cout << "Loaded shared library: " << path << std::endl;

// Release the memory for the string with path.
MFXDispReleaseImplDescription(loader, h);

oneVPL implementation on Intel^® platforms with X^e architecture and Intel^® Media Software Development Kit Coexistence

oneVPL supersedes Intel^® Media Software Development Kit and partially binary compartible with Intel^® Media Software Development Kit. Both oneVPL and Intel^® Media Software Development Kit includes own dispatcher and implementation. Coexistence of oneVPL and Intel^® Media Software Development Kit dispatchers and implementations on single system is allowed until Intel^® Media Software Development Kit is not EOL.

Usage of the following combinations of dispatchers and implementations within the single application is permitted for the legacy purposes only. In that scenario legacy applications developed with Intel^® Media Software Development Kit will continue to work on any HW supported either by Intel^® Media Software Development Kit or by the oneVPL.

Attention

Any application to work with the oneVPL API starting from version 2.0 must use only oneVPL dispatcher.

Intel^® Media Software Development Kit API

Intel^® Media Software Development Kit API of 1.x version.

Removed API

Intel^® Media Software Development Kit API which is removed from oneVPL.

Core API

Intel^® Media Software Development Kit API without removed API.

oneVPL API

New API introduced in oneVPL only started from API 2.0 version.

oneVPL Dispatcher API

Dispatcher API introduced in oneVPL in 2.0 API version. This is subset of oneVPL API.

oneVPL for Intel^® platforms with X^e architecture and Intel^® Media Software Development Kit

Dispatcher	Installed on the device	Loaded	Allowed API
oneVPL	oneVPL for Intel® platforms with Xe architecture	oneVPL for Intel® platforms with Xe architecture	Usage of any API except removed API is allowed.
oneVPL	Intel® Media Software Development Kit	Intel® Media Software Development Kit	Usage of core API plus dispatcher API is allowed only.
oneVPL	oneVPL for Intel® platforms with Xe architecture and Intel® Media Software Development Kit	oneVPL for Intel® platforms with Xe architecture	Usage of any API except removed API is allowed.
Intel® Media Software Development Kit	oneVPL for Intel® platforms with Xe architecture	oneVPL for Intel® platforms with Xe architecture	Usage of core API is allowed only.
Intel® Media Software Development Kit	oneVPL for Intel® platforms with Xe architecture and Intel® Media Software Development Kit	Intel® Media Software Development Kit	Usage of Intel® Media Software Development Kit API is allowed.
Intel® Media Software Development Kit	Intel® Media Software Development Kit	Intel® Media Software Development Kit	Usage of Intel® Media Software Development Kit API is allowed.

Note

if system has multiple devices the logic of selection and loading implementations will be applied to each device accordingly to the system enumeration.

Multiple Sessions

Each oneVPL session can run exactly one instance of the DECODE, ENCODE, and VPP functions. This is adequate for a simple transcoding operation. If the application needs more than one instance of DECODE, ENCODE, or VPP in a complex transcoding setting or needs more simultaneous transcoding operations, the application can initialize multiple oneVPL sessions created from one or several oneVPL implementations.

The application can use multiple oneVPL sessions independently or run a “joined” session. To join two sessions together, the application can use the function MFXJoinSession(). Alternatively, the application can use the MFXCloneSession() function to duplicate an existing session. Joined oneVPL sessions work together as a single session, sharing all session resources, threading control, and prioritization operations except hardware acceleration devices and external allocators. When joined, the first session (first join) serves as the parent session and will schedule execution resources with all other child sessions. Child sessions rely on the parent session for resource management.

Important

Applications can join sessions created from the same oneVPL implementation only.

With joined sessions, the application can set the priority of session operations through the MFXSetPriority() function. A lower priority session receives fewer CPU cycles. Session priority does not affect hardware accelerated processing.

After the completion of all session operations, the application can use the MFXDisjoinSession() function to remove the joined state of a session. Do not close the parent session until all child sessions are disjoined or closed.

previous

Status Codes

next

Frame and Fields