SetAcceleration returns MFX_ERR_UNSUPPORTED

maxim-sharabayko

Mar, 11/01/2011 - 03:53

Hello!

I want to test Intel Media SDK DirectShow filters, particulary H.264 Video Encoder. The problem I faced is that I cannot connect the H.264 Enc filter, even when I try to connect on Media SDK MPEG-2 Decoder, which, BTW, connects is properly connected.

So I debugged H.264 Decoder and found out that it fails to dispatch:
function call to SetAcceleration(MFX_IMPL_AUTO); in CBaseEncoder::CBaseEncoder() returns -3, which is MFX_ERR_UNSUPPORTED.

The version passed is Minor 1 Major 1 Version 65537. I tryed to pass Minor 0, Major 1, but didn't work.
Implementation is set to MFX_IMPL_AUTO. I also tryed MFX_IMPL_SOFTWARE, but didn't work!
MediaSDK is 2.0 Gold (downloaded today).

I checked that libmfxsw32.dll is in the same folder as the filter. hardware version (libmfxhw32.dll) I don't have for unknown reason.

Please help me to fix this problem as I don't have any more ideas on what to do!

23 post / 0 new

Ultimo contenuto

Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

Accedi per lasciare commenti

Nina Kurina (Intel)

Mar, 11/01/2011 - 09:19

Hi maxlovic,
Did you use the Media SDK 2.0 msi installer on the system you are trying to run DShow filters? The issue you describe seems to be in the inability to find the Media SDK dll. The folder with libmfxsw32.dll must be either in the PATH (normally added by installer) or in the same folder with application, which would be GraphEdt.exe, but not filter binary.
Hardware implementation is not included in Media SDK 2.0 package, hardware libs are delivered with Intel Graphics drivers for the respective platforms (the only exception is libmfxhw32.dll in Media SDK 1.0 and 1.5 which is the implementation for G45/GM45 platforms). Which platform would you like to run the Media SDK on?
Regards, Nina

Accedi per lasciare commenti

maxim-sharabayko

Mar, 11/01/2011 - 20:57

Hi Nina!

Yes, I used Media SDK 2.0 msi installer. It added C:\Program Files (x86)\Intel\Media SDK\2.0.12.24071\bin\win32; to my PATH environment variable.

Maybe the problem is in x64 Windows version? I use Win 7 x64. Previously I had x64 Media SDK Beta version, and yesterday installed Media SDK 2.0 x64 Gold version. I built Media SDK sample with win32 configuration. Direct Show is also x64 version.

Now I uninstalled all Media SDK packages and set up Media SDK 2.0 x32 GOLD, but it seems the problem remains.

Update: No, sorry. Now the problem is solved. So it was somewhere around x64 and x32 interoperation. Thanks!
Now the major problem is to feed the encoder with NV12 videoframe.

Update: Ok, we set everything to work!
Nina, hardware library libmfxhw32.dll is installed with Intel Graphics Driver. Will hardware mode work with platforms, that do not have Intel Embedded Graphics (e.g. Intel Code 2 Duo and a video card with DXVA support)? Videocard manufacturers should include this library with their driver or they cannot create libmfxhw32.dll?

Accedi per lasciare commenti

Nina Kurina (Intel)

Mer, 12/01/2011 - 08:35

Glad to hear that you resolved the configuration issue.
As for hardware libraries, Intel Media SDK has implementations for specific Intel platforms only. So hardware mode would work only on supported platforms provided that platform-specific libraries are in the system.
libmfxhw32.dll is not universal in any way. libmfxhw32.dll is optimized for Intel G45 (and GM45) Express Chipset. There are also libraries for Intel HD Graphics (coming with Core ix processors and 2nd generation of Core ix processors, the latter aka SandyBridge microarchitecture). These libraries are installed by graphics drivers and have specific names.
For more details you may check out this blog posthttp://software.intel.com/en-us/blogs/2010/12/07/intel-media-sdk-20-dispatching-explained/
Best regards, Nina

Accedi per lasciare commenti

maxim-sharabayko

Mer, 12/01/2011 - 21:01

Nina,

Thanks for your reply and for the link. I still don't quite understand the thing I left in the comment to that article:

"Does Intel Media SDK support hardware mode on Intel platform with no embeded graphics chipset?
Say we have Intel Core 2 Duo processor, and some video card with DXVA. Will Intel Media SDK decoders be able to utilize the possibility to decode MPEG-2 on DXVA?"

And one more thing about the usage possibilities. As I understand we can only query implementation of one of the codecs, which is stored inside some dll, supplied with the SDK. So we don't have acces to modify codec's core?

Accedi per lasciare commenti

Nina Kurina (Intel)

Gio, 13/01/2011 - 10:40

Quoting maxlovic "Does Intel Media SDK support hardware mode on Intel platform with no embeded graphics chipset?
Say we have Intel Core 2 Duo processor, and some video card with DXVA. Will Intel Media SDK decoders be able to utilize the possibility to decode MPEG-2 on DXVA?"

The answer is no. MSDK decoders won't be able to utilize DXVA on an arbitrary architecture.

Sorry, I'm not sure I understand this question. Could you please reformulate or explain with examples?

Regards,

Nina

Accedi per lasciare commenti

maxim-sharabayko

Gio, 13/01/2011 - 19:41

Nina, hi!

Well, DXVA is not utilized on arbitrary architecture, ok.

Yesterday we tryed to test software mode of H.264 encoder on AMD architecture - it also didn't work: the filters are connecting, but at the start the graph says that it can't run.

Also, as I read somewhere earlier, IntelHD graphics won't work on some architectures, where there is also a discrete video card in use. Only latest chipset will be able to use processor GPU and video card GPU both.

Conserning the engine, I mean that the coding engine itself is hidden in dll. We can only acces the available implemented functions, but cannot modify them. Media SDK samples are in fact a kind of wrapper. So that means we cannot change Media SDK's engine to add DXVA support on arbitrary architecture and some other functions we like, or modify the existing one. We can only use these functions where we need.

So, we should use our, say H.264 coding engine everywhere, but when the encoder is run on Intel HD compatible processor, we can switch to use Media SDK engine in hardware mode.

Accedi per lasciare commenti

Nina Kurina (Intel)

Lun, 17/01/2011 - 09:34

Hi Maxlovic,
Sorry for delay with answer, I needed some time to gather the information.

Actually the software implementation of Media SDK can work on any x86 compatible processor. You likely have an installation/configuration problem on that AMD system. Please double check that libmfxsw32.dll is in the DLL search path (PATH environmental variable or application's local directory).
Regarding Intel's embedded graphics and discrete graphics together - you are right, there is a known limitation.
HW Media SDK libs for G45/GM45 and Intel HD Graphics on Core i3,5,7 would work only if Intel's graphics is the primary display adapter.
Starting with API 2.0 (HW lib for Intel HD Graphics on 2nd generation of Core ix aka SandyBridge) there is a possibility to run the lib on the specified or auto-selected display adapter which solves the problem for an arbitrary case.
And coming back to your question about the engine. Your understanding is correct - decoding, encoding and video preprocessing algorithms are implemented in the particular library (dll) which you cannot modify. Media SDK samples use the Media SDK API and therefore can work with any library that implements this API.
So, you're right about this: Quotingmaxlovic So, we should use our, say H.264 coding engine everywhere, but when the encoder is run on Intel HD compatible processor, we can switch to use Media SDK engine in hardware mode.
Best regards, Nina

Accedi per lasciare commenti

maxim-sharabayko

Lun, 17/01/2011 - 20:16

Hi Nina,

Thanks for your reply. It is all crear now.

Regarding the following issue:
"Actually the software implementation of Media SDK can work on any x86
compatible processor. You likely have an installation/configuration
problem on that AMD system. Please double check that libmfxsw32.dll is
in the DLL search path (PATH environmental variable or application's
local directory)."

When we delete libmfxsw32.dll from the folder we have it in, the filters are not even connecting. When this lib stays, the filters are connecting, but either graph can't play (as with media sdk mpeg-2 decoder), or works, but has no output (as with h.264 encoder, which loads the processor up to 85%, but no output is produced, nor the statistics Number of frames encoded is updated from 0).

As we had the same approach working on intel xeon based PC, we thought it is because AMD is not supported.

Regards,

Maxim Sharabayko

Accedi per lasciare commenti

Nina Kurina (Intel)

Mar, 18/01/2011 - 04:51

Hi Maxim,
Now I see, the problem must be in something else.
Please share the details of the experiment - processor model,OS, Media SDK package name (to double check), streamresolution, bitrate etc - so that we could reproduce your case.
Maybe you could debug the sample code to see where an error occurs in case of MPEG2 decoding and where the code waits that long in the encoding case?
Maybe also try a lighter workload (e.g. a CIF stream) and check if the behaviour is same.
Thank you, Nina

Accedi per lasciare commenti

maxim-sharabayko

Mar, 18/01/2011 - 06:19

Nina,

The configuration is the following: AMD phenom 2 840, OS Win7.
We ran successfully on Intel Xeon 5355 - win7 and Intel Core 2 Duo - Win 7.
All software in mode.
Default settings (couldn't change them on H.264 Encoder, as I remember).

Unfortunatelly I do not have this AMD-based computer close at head, so I am not able to debug it.

Accedi per lasciare commenti

Nina Kurina (Intel)

Mar, 18/01/2011 - 07:34

Could you please confirm the steps to reproduce your experiment:
- install Media SDK 2.0 Gold (32/64?) - run GraphEdt - chain FileSource-Intel Mpeg2 Splitter-Intel Mpeg2 Decoder-EVR -> Graph Cannot Play - chain FileSource-AVI Splitter- ColorConverter-Intel H264 Encoder-Muxer-FileWriter -> No output while high CPU usage
Correct?
Win7 32 or 64 bit?
Please also specify input streams resolutions.
Thanks, Nina

Accedi per lasciare commenti

maxim-sharabayko

Mar, 18/01/2011 - 07:47

- install Media SDK 2.0 Gold (32-bit)
- distribute built DS filters and libsw32.dll to another computer
- register filters - run GraphEdt - chain FileSource--Intel Mpeg2 Decoder-EVR -> Graph Cannot Play regadless from the filter after the decoder - chain - CSC - H264 Encoder - Null Renderer or any other filter
No output while high CPU usage
Win7 32, but I will ask this one to be sure.

Resolution 1080x720, but it seems not to play any role. Lower resolution produces the same behaviour.

Accedi per lasciare commenti

Nina Kurina (Intel)

Mar, 18/01/2011 - 08:11

Well, my guess was that it could be a performance issue - but now I doubt that it is so - as you say resolution doesn't even matter..
You say that exactly same chains and configurations work on Xeon, same streams, correct? So it should not be a compatibility issue between your DS filters and Intel's.
We will double check the DShow decoding/encoding on an AMD-based system.
Running console decode/encode (check out sample_decode and sample_encode under \samples folder of Media SDK package) could help to localize the issue. May I ask you to do a quick experiment and run those samples on the AMD system? But please note that sample_decode takes elementary video as input and sample_encode - raw YUV - you will probably need to extract those from your test streams. Nina

Accedi per lasciare commenti

maxim-sharabayko

Mar, 18/01/2011 - 08:29

Yes, all test conditions are the same on Phenom and Xeon.

I will try to get results on console transcoder tomorow. What exactly do you need as a feedback on this test?

By the way, I am not quite sure that sample decode will be able to take YV12 stream, as it seams everything works on NV12. Or does it have internal CSC?

Accedi per lasciare commenti

Nina Kurina (Intel)

Mar, 18/01/2011 - 08:48

I would like to know if console samples (simple decoding and encoding) are functional on that AMD system.
The experiment with DS samples is always kind of complicated and has too many dependencies. A run of console samples would show whether the problem is truly in the processor type.
Sample_encode accepts YV12 as input (Y,U,V order) and does have an internal CSC. Sample_decode accepts elementary mpeg2, h.264 and vc1 formats. I'll wait for your results! Thank you, Nina

Accedi per lasciare commenti

Nina Kurina (Intel)

Ven, 21/01/2011 - 04:53

Maxim, hi!
Did you get a chance to check console decode/encode on your AMD system?
-Nina

Accedi per lasciare commenti

maxim-sharabayko

Dom, 23/01/2011 - 21:30

Hi Nina,

Sorry for taking so long to check console version.
It seems it works fine on our AMD system.

Maxim

Accedi per lasciare commenti

maxim-sharabayko

Dom, 23/01/2011 - 23:34

Nina,

BTW I have one more question about hardware mode.

1. Let's assume we are transcoding from mpeg-2 to H264 video. Will both Intel Media SDK MPEG-2 Video Decoder and H264 Encoder work in hardware mode and do they use some common Sandy Bridge modules, EUs etc.?
2. Now let's say we have several such transcoding proccesses. Will they all run in hardware mode and will they be able to utilize common GPU resources?

Maxim

Accedi per lasciare commenti

Nina Kurina (Intel)

Mar, 25/01/2011 - 08:42

Hi Maxim, Thanks for carrying out this experiment . Your results show that the Media SDK library itself functions on this system. The problem with DirectShow chains looks more like filters compatibility issue (Yours/Intel's). If you'd like to go on with this problem investigation, could you please check if the chain "FileSource-Intel Splitter-Intel Decoder-EVR" is functional. Or let me know if you no longer need our assistance with this issue. Nina

Accedi per lasciare commenti

Nina Kurina (Intel)

Mar, 25/01/2011 - 09:22

Quoting Maxim Sharabayko 1. Let's assume we are transcoding from mpeg-2 to H264 video. Will both Intel Media SDK MPEG-2 Video Decoder and H264 Encoder work in hardware mode and do they use some common Sandy Bridge modules, EUs etc.? Nina: Yes, both decoder and encoder will work in HW mode. And they do use common MFX engine which is a fixed function. Only Encode uses EUs, decode is fully done in FF. You can find a good picture here
2. Now let's say we have several such transcoding proccesses. Will they all run in hardware mode and will they be able to utilize common GPU resources?

Nina: No problem with several transcoding processes as well - they will all run in HW mode and use common GPU resources.

Accedi per lasciare commenti

maxim-sharabayko

Mar, 25/01/2011 - 09:23

Best Reply

Hi Nina,

Ok, the problem may be in DirectShow chain. We are just studying the major functionality of Media SDK, therefore there is no need for us to continue the problem investigation. I think it is easyer to debug the filters to find the problem.

Thanks for the reply on hardware mode.

Maxim

Accedi per lasciare commenti

Nina Kurina (Intel)

Mar, 25/01/2011 - 09:25

Ok, I see and totally agree about debug :-) We can comeback to that issue later if needed. You are always welcome! Nina

Torna al post originale

Intel® Developer Zone

SetAcceleration returns MFX_ERR_UNSUPPORTED

SetAcceleration returns MFX_ERR_UNSUPPORTED

Accedere per lasciare un commento.