- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?
- Tags:
- Bug
- Development Tools
- Graphics
- Intel® Media SDK
- Intel® Media Server Studio
- Media Processing
- Optimization
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page