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.
3072 Discussions

VPL decode works, but encode fails : not sure about system requirements

chatelier__pierre
2,026 Views

Hello,

I just gave a try to oneAPI VPL (2021.1-beta05)

During installation, it complained about unsupported OS. It required at least Win7* 64 Intel, which is precisely the one I run, so that was a first issue. Was it a bug of the installer, or a wrong system requirements description ?

Then I built a sample code to decode H264 with the vplWorkstream : it worked flawlessly (in TARGET_DEFAULT mode, TARGET_GPU won't run on my machine)

Finally, I built a sample code to encode H264 from raw YUV, and this time it failed. No error is raised by all the configuration, but EncodeFrame() returns 0 bytes and immediately sets the encoder's state to VPL_STATE_ERROR. Since it could be a misuse of my code, I switched to the sample code from https://github.com/intel/BaseKit-code-samples/tree/master/VideoProcessingLibrary/07_encode_simple, and the behaviour is exactly the same : no visible error, until EncodeFrame() is called and returns 0 bytes with a VPL_STATE_ERROR state.

So I suspect that encoding is not supported on my system, but why, since decoding works ?

I also tried to use VPL_PROP_STATUS_CALLBACK, but no prototype is given in the header files, so I tried to guess it as

void myStatusCallback(vpl::Workstream* encoder, vplWorkstreamState status, void* data)

but it is never called anyway.

Is there a way to trace deep errors ?

 

 

0 Kudos
5 Replies
Mark_L_Intel1
Moderator
2,026 Views

Hi Pierre,

Thanks for trying our product and give us value feedback.

There are several issues in our message. First, I want to fix the Windows support issue and I am investigating it now. I have checked VPL system requirement page, it says only support Windows 10. I guess you might get support info like "Win7* 64" from somewhere else which is a misleading. 

Could you help me to point out where you got it?

We are also working on other issues you reported, and the issues seems related to the GPU capability. Could you give me more information about your hardware platform? It looks like you were using Windows 10 for other sample related issues, what is your processor?

The issues are also point to the features missing from our API. So from your report, we have following issues in our list:

  • System Requirement misleading on Windows 7.
  • ARGET_DEFAULT behavior confusing, there is no way to tell which hardware the default is using.
  • The reason why EncodeFrame() call failing should be missing GPU capability.
  • missing document for VPL_PROP_STATUS_CALLBACK usages.

Mark Liu

0 Kudos
chatelier__pierre
2,026 Views

Hello,

First, about the system requirements. See the attached screenshot below from the installer. Please note that I just ignored this warning since I am running Windows 7 64 Pro. And please note that the VPL decoder does work very well !

Now, if you want to know my platform, I have also attached CPU-Z report.

 

 

0 Kudos
Mark_L_Intel1
Moderator
2,026 Views

Thanks for the valuable feedback,

I will submit a request to fix the issues. I realized there is one more issue except OS support: VPL support processor version 6th and above, so if user has Haswell like you, he should be notified.

https://software.intel.com/en-us/articles/oneapi-video-processing-library-system-requirements

Mark Liu

0 Kudos
chatelier__pierre
2,026 Views

I understand that encoding may have extra restrictions and requires W10 or Skylake, but decoding is very valuable for me as an alternative to MSMF that is plagued by some bugs. If you can keep decode backward compatibility to W7 and older processors, it woudl be great !

Instead of opening a new thread, here is a new feddback :

the API should have functions to check for run-time availability (currently I can just try to build a workstream and see if it fails), a function to check the current version, and macros or constants in the header files to hard-encode the version used at compile-time.

0 Kudos
Mark_L_Intel1
Moderator
1,918 Views

Hi Pierre,


Sorry for not being update on this issue. We have confirmed the issue was resolved by our Gold release posted today.


Please post a new request if you observe new issues on the installer.


Mark


0 Kudos
Reply