I don't need or necessarily want to uninstall Media SDK.
I am just curious if hardware acceleration is not available, if Media SDK will fall back to software only encode and decode similar to Windows. I've only seen one mention of Software Fallback not being available under some circumstances. Just wanted to get specific information.
vade@vRareVolumeDev:~/Downloads/mediasdk-tutorials-0.0.3/_build$ ./simple_decode .
libva info: VA-API version 0.99.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
terminate called after throwing an instance of 'std::bad_alloc'
Aborted (core dumped)
Which tells me there is no fallback to software decode if libVA doesnt have / find hardware acceleration.
If I have an application binary compiled that uses the Media SDK and I attempt to run it in a configuration where hardware acceleration isn't available, will the Media SDK on Linux fall back to software or not?
If MFXInit function is called with appropriate impl parameter, there will be able fallback mechanism.
You can refer to documentation:
The function MFXInit starts (initializes) an SDK session. MFXClose closes (de-initializes) the SDK session. To avoid memory leaks, always call MFXClose after MFXInit.
The application can initialize a session as a software-based session (MFX_IMPL_SOFTWARE) or a hardware-based session (MFX_IMPL_HARDARE,). In the former case, the SDK functions execute on a CPU, and in the latter case, the SDK functions use platform acceleration capabilities. For platforms that expose multiple graphic devices, the application can initialize the SDK session on any alternative graphic device (MFX_IMPL_HARDWARE1…MFX_IMPL_HARDWARE4).
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.
Is this actually true for Linux?, it was previously the case that this was not true.
Has something changed and now there is software encode/decode/transcode fallback for Linux???
Jeffrey McCallister said: "For Linux, fallback to SW can only happen if the HW implementation can start -- there isn't a general purpose SW implementation. If general portability is a concern you'll probably want to implement your own fallback path." - in this link: https://software.intel.com/en-us/forums/intel-media-sdk/topic/531608
If there is not a libmfxsw64.so, or whatever distributed with the Linux version, I doubt there is true software fallback support.
We do ship a software implementation in Linux now. If you check /opt/intel/mediasdk/lib64 in recent releases there is a libmfxhw64 and libmfxsw64 shared library.
Perhaps it will help to describe some scenarios:
- Application starts the session with MFX_IMPL_SOFTWARE: The application can use a wide variety of methods, including attempting to start a HW implementation first, to determine which type of implementation to start.
- Application starts the session with MFX_IMPL_AUTO/MFX_IMPL_AUTO_ANY. Media SDK will try HW acceleration first, and if not available run in software. This is similar to Media SDK automating scenario #1 and happens at session initialization.
- Scenario 1 and 2 happen at session init. There is another type of software fallback that happens when a session is started with the hardware implementation but then either after the first initialization or a parameter update there is a combination of parameters which cannot be run in HW but can be supported by the SW implementation. In this case when the Media SDK stage (decode, encode, VPP) is initialized a status of MFX_WRN_PARTIAL_ACCELERATION is returned.
Scenario 1 and 2 require the SW implementation library to be present. Scenario 3 only requires the HW implementation, since a SW implementation is wrapped inside the HW implementation to handle this case. Scenario 3 was available before the SW implementation was included, but now all three are possible.
Hope this helps, Jeff