Sandy Bridge hardware acceleration

[Kevin_Michalski]

I have Intel Media SDK version 2.0 (Gold) installed on my system. I am attempting to encode H.264 video in hardware and am running into trouble. I have built and run the sample_encode.exe project, and everything works fine if i leave out the -hw switch. When trying the same encode using -hw, the MFXInit function returns MFX_ERR_UNSUPPORTED. I saw that someone else ran into this issue and solved it by switching the default display adapter in BIOS and/or using MFX_IMPL_HARDWARE_ANY instead of MFX_IMPL_HARDWARE to initialize; however, nothing works. I am using the i5-2500 Sandy Bridge CPU with an MSI H67MA-E35 motherboard. The system is running Windows 7. Is there something I am missing here?

Also, once I get this up and running, I will be using DirectShow to develop. Is hw encoding acceleration possible using the the sample H.264 filter, or will I need to customize it?

Thanks in advance for your help.

[Eric_S_Intel]

Hi Kevin,

The Media SDK version 2.0 Gold download package only contains the software implementation libraries. The hardware implementation is installed by the graphics driver.

Can you check \program files\Common\Intel\MediaSDK\s1\2.0 to ensure the hardware implementation libraries are on your system? Also, if you are building a 32bit app and running 64bit check the same dir structure under \program files (x86)\.. If they are not present, then simply update your video driver.

The h.264 DirectShow filter supports hw encoding however its a sample and is not production quality.

-Eric

[Kevin_Michalski]

Eric,

I've installed the latest graphics drivers from the Intel site (8.15.10.2291). I have also verified that the folder you mentioned is present. Among other files, there is one named libmfxhw32-s1.dll--is that the necessary library? I am running a 32-bit installation, by the way.

What should I try next? I really need to get this up and running for a demo.

[Eric_S_Intel]

Yes, libmfxhw32-s1.dll is the Sandy Bridge hardware implementation library. If the file is present and cant be loaded, then there could be a few things that can be going on.

- Theres a discrete card in your system thats set as the primary video card. This will turn off QSV, and prevent the HW DLL from loading

- The registry values are incorrect which prevents the MSDK dispatcher from finding libmfxhw32-s1.dll

Theres a document in the SDK under \docs\ called mediasdk-distrib that describes how the dispatcher loads the hardware implementation. In the doc you will find that if the dispatcher cant find the platform specific implementation (because the registry is incorrect), it will fall back to the reserved hardware libs. Assuming that QSV is active, you should be able to copy libmfxhw32-s1.dll to libmfxhw32.dll and co-locate that renamed DLL in the same working dir as sample_encode to bypass the dispatcher search. Try that.

Also, sample_encode comes with code. Can you recompile in debug mode and let me know where its returning MFX_ERR_UNSUPPORTED?

Thanks

-Eric

[Kevin_Michalski]

Eric,

Thanks for your help. I dropped in the file you mentioned and lo and behold, I no longer get the error. I loaded up my DS graph and encoding seemed to work flawlessly, with CPU load under 20%. With regard to the sample_encode app, the process runs, but the end file does not seem to work. I am using the following command line:

sample_encode.exe h264 -i d:\MpegFiles\YUV\madmenout.yuv -o d:\MpegFiles\YUV\madmen.h264 -w 1920 -h 1080 -hw

Without the -hw switch, the output file will play back using VLC, but with massive stuttering. With hardware encoding turned on, the resulting file ends up ~400 KB smaller, and crashes VLC when opened. I get similar results when encoding as MPEG-2: software version plays, hardware does not, slight difference in file size. Could my input file be bad? It was created from a MPEG-2 bitstream using the sample_decode utility. I'm not overly concerned about this at the moment, as the DS filter seems to work, but it would be nice to know why this is happening.

As far as the dispatcher not working correctly, what is the next step?

-Kevin

[Eric_S_Intel]

Good news that you got it working. The dispatcher uses HKLM\Software\Intel\MediaSDK\Dispatch\hw64-s1-1 key to find the right DLL to load. Can you verify that you have that key? If its there, then what are the values?

The file sizes are not guaranteed to be identical for SW and HW. They use different algorithms and implementation methods.

About the playback problem Sample_encode creates an elementary video stream. I used to use VLC to playback .264 elementary streams, but as of late Ive noticed that that player doesnt work as well as it used to with elementary streams. Try and mux the file using FFMpeg or XMuxer Pro. Then try playback.

Eric

[Kevin_Michalski]

Eric,

The registry path is there, although the key is named hw32-s1-1, not 64 (I am running a 32 bit installation). The values are as follows:

(Default) (value not set)
APIVersion 0x00000101
DeviceID 0x00000102
Merit 0x0800001b
Path C:\Program Files\Common Files\Intel\Media SDK\s1\2.0\libmfxhw32-s1.dll
VendorID 0x00008086

For the playback problem, I muxed the stream as you suggested and it plays fine.

One other question: in the encoder filters, is there a way to enable/disable hw acceleration through a property, or is it always defaulted to on (if present)?

Thanks again.

[Kevin_Michalski]

Double post

[Eric_S_Intel]

Those registry keys look ok to me. With the exception of a different merit value, ours are identical.

Ive got 0x8000023 for my merit. Try removing that key and reinstalling the driver.

About DShow Encoder, the filter initializes with the MFX_IMPL_AUTO which means use the HW if the DLL is available.

Its in base_encoder.cpp @ line 38. You are free to change it, but theres no property page interface for that.

Another way is to make the DLL fall back to SW by removing the HW DLL.

Eric

[Kevin_Michalski]

Thanks. I don't have the system handy at the moment, but I'll try that when I get a chance.

On a related note, is there a minimal set of files that need to be present on a system for encoding/decoding to work properly, without actually running the installer? If possible, I'd like to be able to incorporate any Intel libraries into my installer package without having to run the Intel MSI first.

[Eric_S_Intel]

It depends.
If you want to use the software implementation with MFX_IMPL_SOFTWARE , then you should includethe libmfxsw(32/64).dll into your installer.This will allow you to run MSDK on non-Intel integrated graphics clients.

The Intel graphics driver will install the HW lib. If you use MFX_IMPL_HARDWARE or MFX_IMPL_AUTO, thenyou dont need to include anything. There's a SW fallback path in the HW DLL. Just make sure you statically link with mfxlib - the dispatcher layer.

Eric

[Kevin_Michalski]

Eric,

I've loaded up another system with the same cpu/mobo and OS. I was able to get hw encoding up and running, but I had to do the same thing as before--renaming and copying the libmfxhw32-s1.dll file. The HKEY_LOCAL_MACHINE\SOFTWARE\Intel\MediaSDK\Dispatch\hw32-s1-1 registry key also has the same values. Any other thoughts as to why the dispatcher does not work as expected?

[Nina_K_Intel]

Hi Kevin,

Sorry for long delay with reply from our side. I have a guess that you are using the Sandy Bridge system in the remote desktop mode, is that right? For that case the dispatcher is not able to match the hw dll installed by the driver because Device & Vendor Id's of the graphic adapter appear zeros. I would suggest you use the VNC tool instead.

Regards,

Nina