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

using MediaSDK server on linux

Oleg_F_
Beginner
381 Views

Hello,
I'm interested in using MediaSDK server on linux for video decoding and encoding tasks and I have several questions:
1) From MediaSDK documentation I understood that it has very strict limitations on linux distro, kernel version and CPU type. These limitations are related to development machine that I'm working on. Is that correct?
2) What about the target machine that I'm going to install the final software? I guess it has the same restrictions. Is that correct?
3) What happens if the target machine does not meet those requirements? Fallback to software only implementation?
4) Is it required to install MediaSDK on target machine? My project should be linked with the appropriate libraries? Static libraries or shared objects?
Thanks in advance,
Oleg Fomenko

 

0 Kudos
1 Solution
Jeffrey_M_Intel1
Employee
381 Views

Hi Oleg,

The limitations are at the driver level, so development and target machines all need to use supported configurations.  We're working on ways to make these requirements less rigid in the future.  The basic concept is "supported" configurations and "secondary" configurations.  For Intel to help with processing issues they will need to be reproducible on supported configurations matching the release notes.  However, we'll provide patches for a specific version of kernel source downloadable from kernel.org which is expected to work in a much wider variety of scenarios.  While this will be a "secondary" configuration (not fully supported unless issues can be reproduced on the limited configuration detailed in the release notes) we hope this will be a step in the right direction.

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.

For distribution, development-only components like include files, samples, etc. are not required.  You should only need the graphics stack components, driver,  libmfxhw*.so, the plugins, and possibly drmserver.  This is also expected to get easier in the future with runtime and developer packages -- though for the current release using the tar.gz method is still recommended.

 

View solution in original post

0 Kudos
1 Reply
Jeffrey_M_Intel1
Employee
382 Views

Hi Oleg,

The limitations are at the driver level, so development and target machines all need to use supported configurations.  We're working on ways to make these requirements less rigid in the future.  The basic concept is "supported" configurations and "secondary" configurations.  For Intel to help with processing issues they will need to be reproducible on supported configurations matching the release notes.  However, we'll provide patches for a specific version of kernel source downloadable from kernel.org which is expected to work in a much wider variety of scenarios.  While this will be a "secondary" configuration (not fully supported unless issues can be reproduced on the limited configuration detailed in the release notes) we hope this will be a step in the right direction.

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.

For distribution, development-only components like include files, samples, etc. are not required.  You should only need the graphics stack components, driver,  libmfxhw*.so, the plugins, and possibly drmserver.  This is also expected to get easier in the future with runtime and developer packages -- though for the current release using the tar.gz method is still recommended.

 

0 Kudos
Reply